Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ansgar]

On Tue, 05 Jul 2022 17:44:14 -0500 Matthias Maier wrote:
> I think this is an issue with the Hardware token and not with the
> userland libraries and tools.

I too tried with a YubiKey 5 (Firmware 5.4.3). The signature was fine
with those.

So it looks indeed likely that this is a firmware bug that was fixed.

Ansgar

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ansgar]

Hi,

On Tue, 2022-07-05 at 09:00 +0200, Bastian Blank wrote:
> On Mon, Jul 04, 2022 at 10:34:39PM +0200, Ansgar wrote:
> > As a further test I tried a different PKCS#11 module:
> 
> Could you try the same with "openssl cms"?  Just to make sure it's
> not sign-file itself.

I replaced the `./sign-file` call with:

+---
| openssl cms -sign -binary -outform DER -engine pkcs11 \
| -keyform engine -inkey "${pkcs11_uri}" -signer ${cert_path} \
| -md sha256 -nocerts -noattr -nosmimecap \
| -in data.ko -out data.ko.p7s
+---

and got the same results as with sign-file, both with
libykcs11.so.2.2.0 and opensc-pkcs11.so.

All of this happened on my laptop running a current Debian testing.

There is at least one ykcs11-specific bug (missing the initial zero
bytes), but the broken signature itself happens with both modules.

Ansgar

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Bastian Blank]

On Mon, Jul 04, 2022 at 10:34:39PM +0200, Ansgar wrote:
> As a further test I tried a different PKCS#11 module:

Could you try the same with "openssl cms"?  Just to make sure it's not
sign-file itself.

The complete command line I use to create signatures for kernel modules
is:

| openssl cms -sign -binary -outform DER -signer "$SIGNING_KEY_FILE" -md sha256 
-nocerts -noattr -nosmimecap -in "$filein" -out "$fileout"

Bastian

-- 
Immortality consists largely of boredom.
-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8

Bug#1012741: Subject: Re: Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Daniel Lewart]

It's like déjà vu all over again:
#942881 - snd-hda-codec-hdmi signature corruption
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942881

Thank you!
Dan
Urbana, Illinois

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ansgar]

Hi,

On Mon, 2022-07-04 at 22:00 +0200, Ansgar wrote:
> The correct signature (using OpenSSL) has:
> 
> +---
> > 138 256:   OCTET STRING
> >    : 00 00 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6
> +---[ data.ko.p7s.success ]
> 
> The incorrect signature from the YK has:
> 
> +---
> > 138 254:   OCTET STRING
> >    : 82 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6 E7
> +---[ data.ko.p7s.fail ]
> 
> So there is also a wrong byte at the beginning.
> The incorrect signature also misses one byte at the end.

As a further test I tried a different PKCS#11 module:

Modify reproduce.sh and set

+---
| 
pkcs11_uri="pkcs11:token=Test%20Key;manufacturer=piv_II;model=PKCS%2315%20emulated"
| export PKCS11_MODULE_PATH=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
+---

This results in yet a different error:

+---
| 138 256:   OCTET STRING
|: 00 00 82 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C
+---

The total size is correct, but it includes one incorrect byte at the
beginning (byte #3, 0x82) and the last byte is missing.

I've attached this signature as well.

Ansgar




data.ko.p7s.fail-opensc
Description: Binary data

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ansgar]

Hi,

I experimented a bit more and could reproduce the problem with a local
YK (Yubikey 4, Firmware 4.3.7) and a known private key and certificate.

The correct signature (using OpenSSL) has:

+---
| 138 256:   OCTET STRING
|: 00 00 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6
+---[ data.ko.p7s.success ]

The incorrect signature from the YK has:

+---
| 138 254:   OCTET STRING
|: 82 45 75 A8 93 B1 B1 37 0A 53 69 82 BB 1C B6 E7
+---[ data.ko.p7s.fail ]

So there is also a wrong byte at the beginning.
The incorrect signature also misses one byte at the end.

The attached archive contains:

 - data.ko: random data to be signed
 - data.ko.p7s.fail: incorrect signature generated by YK4
 - data.ko.p7s.success: correct signature generated by OpenSSL
 - reproduce.sh: sign with YK4 (set serial# in the first lines)
 - reproduce2.sh: sign with OpenSSL
 - sign-file: make this a symlink to linux' sign-file
 - test.key: private key
 - test.pem: self-signed certificate

The test.{key,pem} need to be loaded in the Digital Signature (Slot 9c)
slot of the PIV application.

I haven't checked if this is reproducible with another YK with the same
data/key/cert, but it is reproducible with the same key.

Ansgar



ykcs11-signature-failure.tar.gz
Description: application/compressed-tar

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Mon, 2022-07-04 at 14:04 +0200, Ansgar wrote:
> On Sun, 19 Jun 2022 12:59:55 +0200 Ben Hutchings wrote:
> > > I'm now looking at whether the missing bytes are recoverable (e.g. are
> > > they always zeroes).
> > [...]
> > 
> > I wrote a script to try all possible byte values for 2 bytes before or
> > after the short signature.  For this particular file, none of them
> > producd a valid signature.  So the short signatures seem to be
> > corrupted in a more complex way.
> 
> The "OCTET STRING" containing the actual signature is shorter for the
> seemingly corrupted signatures:
[...]

Yes I know, and my script uses a library to manipulate the ASN.1
structure when adding bytes.  I'm attaching the script, so you can
check the logic.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.
#!/usr/bin/python3

# Fix broken detached signatures

import os.path
import sys

import asn1crypto.algos
import asn1crypto.cms
import asn1crypto.core

from M2Crypto import BIO, SMIME, X509


# Signature algorithm should be RSA
SIG_ALGO_OID = asn1crypto.core.ObjectIdentifier('1.2.840.113549.1.1.1')


# Signature length should match key length (2048 bits)
SIG_LEN = 2048 // 8


def make_smime_context(cert):
# We don't verify against a CA, just one specific certificate
smime = SMIME.SMIME()
signer_key = X509.X509_Stack()
signer_key.push(X509.load_cert(cert))
smime.set_x509_stack(signer_key)
smime.set_x509_store(X509.X509_Store())
return smime


def verify_payload(smime, sig, data):
smime.verify(
SMIME.load_pkcs7_bio_der(BIO.MemoryBuffer(sig.dump(force=True))),
BIO.MemoryBuffer(data),
flags=(SMIME.PKCS7_BINARY | SMIME.PKCS7_DETACHED
   | SMIME.PKCS7_NOVERIFY))


def brute_force_sig_2bytes(smime, sig, sig_os, data):
orig_raw_sig = bytes(sig_os)
for byte1 in range(256):
for byte2 in range(256):
sig_os.set(bytes((byte1, byte2)) + orig_raw_sig)
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'prepended {byte1}, {byte2} to start of sig')
return True

sig_os.set(bytes((byte1,)) + orig_raw_sig + bytes((byte2,)))
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'added {byte1}, {byte2} at start and end of sig resp.')
return True

sig_os.set(orig_raw_sig + bytes((byte1, byte2)))
try:
verify_payload(smime, sig, data)
except Exception:
pass
else:
print(f'appended {byte1}, {byte2} to end of sig')
return True

return False


def fix_detached_sig(smime, sig, bin_name):
# The ContentInfo should be a SEQUENCE with signed data at index 1
if len(sig) < 2 or not isinstance(sig[1], asn1crypto.cms.SignedData):
return 'no signed data found', False
sd = sig[1]

# The SignedData should be a SEQUENCE with signer infos at index 5
if len(sd) < 6 or not isinstance(sd[5], asn1crypto.cms.SignerInfos):
return 'no signer infos found', False
infos = sd[5]

# The SignerInfos should be a SET with 1 item
if len(infos) != 1:
return f'found { len(infos) } signer infos; expected 1', False
info = infos[0]

# The SignerInfo should be a SEQUENCE with the signature algorithm
# at index 4 and signature at index 5
if (len(info) < 6
or not isinstance(info[4], asn1crypto.algos.SignedDigestAlgorithm)
or len(info[4]) < 1
or not isinstance(info[5], asn1crypto.core.OctetString)):
return 'expected fields not found in signer info', False

# Check the signature algorithm and length (see bug #1012741)
if info[4][0] != SIG_ALGO_OID:
return f'unexpected signature algorithm { info[4][0].dotted }', False
actual_sig_len = len(bytes(info[5]))

with open(bin_name, 'rb') as f:
data = f.read()

if (actual_sig_len == SIG_LEN - 2
and brute_force_sig_2bytes(smime, sig, info[5], bin_name)):
return (f'signature length is { actual_sig_len } bytes;'
f' expected { SIG_LEN }; filled in missing 2 bytes',
True)

if actual_sig_len != SIG_LEN:
return (f'signature length is { actual_sig_len } bytes;'
f' expected { SIG_LEN }',
False)

verify_payload(smime, sig, data)
return None, False


def load_detached_sig(name):
with open(name, 'rb') as f:
return asn1crypto.cms.ContentInfo.load(f.read())


def save_detached_sig(sig, name):
with open(name, 'wb') as f:
f.write(sig.dump())


def main(sig_dir, bin_dir, cert):
err_count = 0

smime = make_smime_context(cert)

for dirpath, dirnames, filenames in os.walk(sig_dir):
for 

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ansgar]

On Sun, 19 Jun 2022 12:59:55 +0200 Ben Hutchings wrote:
> > I'm now looking at whether the missing bytes are recoverable (e.g. are
> > they always zeroes).
> [...]
> 
> I wrote a script to try all possible byte values for 2 bytes before or
> after the short signature.  For this particular file, none of them
> producd a valid signature.  So the short signatures seem to be
> corrupted in a more complex way.

The "OCTET STRING" containing the actual signature is shorter for the
seemingly corrupted signatures:

+---
| $dumpasn1 
./linux-image-4.19.0-21-amd64-unsigned/lib/modules/4.19.0-21-amd64/kernel/net/openvswitch/vport-vxlan.ko.sig
|   0 404: SEQUENCE {
| [...]
| 151 254:   OCTET STRING
+---

vs

+---
| $ dumpasn1 
./linux-image-4.19.0-21-cloud-amd64-unsigned/lib/modules/4.19.0-21-cloud-amd64/kernel/net/openvswitch/vport-vxlan.ko.sig
|   0 407: SEQUENCE {
| [...]
| 151 256:   OCTET STRING
+---

Given the number of corrupted signatures is pretty much the number of
signatures where the two leading bytes should be 0 (as stated in [1]),
I suspect something (incorrectly?) outputs a shorter OCTET STRING
leaving out the 0 (as one might for a large integer type), but the
other side expects a fixed size?

If so, the file should validate if one injects two leading 0 bytes in
the OCTET STRING (and updates all length values). I would need to check
how to manipulate files using ASN.1's DER encoding to try this...

Ansgar

  [1]: https://bugs.debian.org/1012741#48

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Daniel Lewart]

Ben, et al,

On Sun, 19 Jun 2022 12:59:55 +0200, Ben Hutchings wrote:
> In the mean time, we have another security update coming which might
> not hit this bug again.  But there are 28,679 signed binaries across
> the three architectures, so the probability is only about 65%.

I looked at the following new (Jul  2, 2022) binaries:
  * linux-image-4.19.0-21-686-pae_4.19.249-2_i386.deb
  * linux-image-4.19.0-21-686_4.19.249-2_i386.deb
  * linux-image-4.19.0-21-amd64_4.19.249-2_amd64.deb
  * linux-image-4.19.0-21-arm64_4.19.249-2_arm64.deb
  * linux-image-4.19.0-21-cloud-amd64_4.19.249-2_amd64.deb
  * linux-image-4.19.0-21-rt-686-pae_4.19.249-2_i386.deb
  * linux-image-4.19.0-21-rt-amd64_4.19.249-2_amd64.deb
  * linux-image-4.19.0-21-rt-arm64_4.19.249-2_arm64.deb

There were 25,011 signed kernel modules, with one bad signature:
  * binary package: linux-image-4.19.0-21-amd64
  * version: 4.19.249-2
  * file: lib/modules/4.19.0-21-amd64/kernel/net/openvswitch/vport-vxlan.ko

Perhaps this bug should be retitled?

Thank you!
Dan
Urbana, Illinois

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Sun, 2022-06-26 at 10:30 -0500, Daniel Lewart wrote:
> Ben, et al,
> 
> On Mon, 13 Jun 2022 18:23:18 +0200 Ben Hutchings  wrote:
> 
> > Since the truncated signatures are in the source packages, this is a
> > problem introduced by the code signing service and will need to be
> > fixed there.
> 
> Assuming that the code-signing service uses the kernel's scripts/sign-file
> and calls PKCS7_sign() ...
> 
> Which version of OpenSSL/libssl is used?

I don't know that; you would have to ask the FTP team.

> Are kernel build logs available for download or viewing?

All package build logs are available from ,
but the code signing step is separate.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


signature.asc
Description: This is a digitally signed message part

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Daniel Lewart]

Ben, et al,

On Mon, 13 Jun 2022 18:23:18 +0200 Ben Hutchings  wrote:

> Since the truncated signatures are in the source packages, this is a
> problem introduced by the code signing service and will need to be
> fixed there.

Assuming that the code-signing service uses the kernel's scripts/sign-file
and calls PKCS7_sign() ...

Which version of OpenSSL/libssl is used?

Are kernel build logs available for download or viewing?

Thank you!
Dan
Urbana, Illinois

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Daniel Lewart]

Ben, et al,

BH> I wrote a script to check for short signatures (and other unexpected
BH> things) in detached signature files:
BH> 
https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/benh/check-sig-params

DL> I tried running your script, but it generates an error (see below).
DL> What am I doing wrong?

I was running it for the kernel module instead of the detached signature.  D'oh!

This works:
$ extract-module-sig.pl -s
/lib/modules/5.10.0-15-amd64/kernel/net/netfilter/xt_l2tp.ko
2>/dev/null | check-sig-params /dev/stdin

Sorry for the noise,
Dan
Urbana, Illinois

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Mon, 2022-06-20 at 04:38 -0500, Daniel Lewart wrote:
> Ben,
> 
> > I wrote a script to check for short signatures (and other unexpected
> > things) in detached signature files:
> > https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/benh/check-sig-params
> 
> Thank you for your excellent detective work!
> 
> I tried running your script, but it generates an error (see below).
> What am I doing wrong?
[...]

I don't know, but I'm running it on unstable.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.


signature.asc
Description: This is a digitally signed message part

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Daniel Lewart]

Ben,

> I wrote a script to check for short signatures (and other unexpected
> things) in detached signature files:
> https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/benh/check-sig-params

Thank you for your excellent detective work!

I tried running your script, but it generates an error (see below).
What am I doing wrong?

Thank you again!
Dan
Urbana, Illinois
---
$ dpkg-query -f='${Package} ${Version}\n' -W python3 python3-asn1crypto
python3 3.9.2-3
python3-asn1crypto 1.4.0-1

$ check-sig-params /lib/modules/5.10.0-15-amd64/kernel/net/netfilter/xt_l2tp.ko
/lib/modules/5.10.0-15-amd64/kernel/net/netfilter/xt_l2tp.ko: Error
parsing asn1crypto.cms.ContentInfo - class should have been universal,
but application was found)

###

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Sat, 2022-06-18 at 16:21 +0200, Ben Hutchings wrote:
> On Thu, 2022-06-16 at 01:28 +0200, Ben Hutchings wrote:
> [...]
> 
> > linux-image-4.19.0-17-amd64 4.19.194-1 
> > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> > linux-image-4.19.0-17-amd64 4.19.194-2 
> > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> > linux-image-4.19.0-17-amd64 4.19.194-3 
> > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> [...]
> > A significant pattern visible here is a short signature for the same
> > module in multiple consecutive versions, where the module may have
> > identical contents.  That implies that this is a reproducible issue for
> > certain inputs that cannot be worked around by re-running the signing
> > process.
> > 
> > However, I have *not* yet verified that all short signatures really are
> > invalid.
> 
> These module files are indeed identical, and their signatures are
> rejected by the kernel.
> 
> I'm now looking at whether the missing bytes are recoverable (e.g. are
> they always zeroes).
[...]

I wrote a script to try all possible byte values for 2 bytes before or
after the short signature.  For this particular file, none of them
producd a valid signature.  So the short signatures seem to be
corrupted in a more complex way.

In the mean time, we have another security update coming which might
not hit this bug again.  But there are 28,679 signed binaries across
the three architectures, so the probability is only about 65%.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
 - Anne Morrow Lindberg


signature.asc
Description: This is a digitally signed message part

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Sat, 2022-06-18 at 16:21 +0200, Ben Hutchings wrote:
[...]
> Incidentally, this is a failure rate of 75 out of 4,967,591 signatures,
> or 0.0015%
[...]

Or maybe not so incidentally: 4,967,591 / 2^16 ~= 75

Ben.


-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.


signature.asc
Description: This is a digitally signed message part

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Thu, 2022-06-16 at 01:28 +0200, Ben Hutchings wrote:
[...]

> linux-image-4.19.0-17-amd64 4.19.194-1 
> lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> linux-image-4.19.0-17-amd64 4.19.194-2 
> lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> linux-image-4.19.0-17-amd64 4.19.194-3 
> lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
[...]
> A significant pattern visible here is a short signature for the same
> module in multiple consecutive versions, where the module may have
> identical contents.  That implies that this is a reproducible issue for
> certain inputs that cannot be worked around by re-running the signing
> process.
>
> However, I have *not* yet verified that all short signatures really are
> invalid.

These module files are indeed identical, and their signatures are
rejected by the kernel.

I'm now looking at whether the missing bytes are recoverable (e.g. are
they always zeroes).

Incidentally, this is a failure rate of 75 out of 4,967,591 signatures,
or 0.0015%, so it's not surprising that other source packages have not
yet been affected.

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.


signature.asc
Description: This is a digitally signed message part

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Mon, 2022-06-13 at 18:23 +0200, Ben Hutchings wrote:
[...]
> I can confirm that this module does not load, and this means it has an
> invalid signature.  The detached signature present in the source
> package seems to be truncated (408 bytes long, where for all other
> modules the detached signature is 411 bytes long).
> 
> The amd64 kernel package is also affected, but for a different module
> (xt_l2tp).
> 
> Since the truncated signatures are in the source packages, this is a
> problem introduced by the code signing service and will need to be
> fixed there.

I wrote a script to check for short signatures (and other unexpected
things) in detached signature files:
https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/benh/check-sig-params

I've now run that over all linux-signed-* packages available on
snapshot.debian.org.  It found short signatures (in all cases, a raw
signature length of 254 bytes rather than 256 bytes) for the following
binary packages, versions, and files:

linux-image-4.19.0-0.bpo.4-686-pae 4.19.28-2~bpo9+1 
lib/modules/4.19.0-0.bpo.4-686-pae/kernel/drivers/usb/storage/ums-realtek.ko
linux-image-4.19.0-0.bpo.4-amd64 4.19.28-2~bpo9+1 
lib/modules/4.19.0-0.bpo.4-amd64/kernel/drivers/iio/gyro/bmg160_i2c.ko
linux-image-4.19.0-0.bpo.4-rt-amd64 4.19.28-2~bpo9+1 
lib/modules/4.19.0-0.bpo.4-rt-amd64/kernel/drivers/mtd/chips/map_ram.ko
linux-image-4.19.0-0.bpo.5-amd64 4.19.37-4~bpo9+1 
lib/modules/4.19.0-0.bpo.5-amd64/kernel/drivers/video/fbdev/via/viafb.ko
linux-image-4.19.0-0.bpo.6-686 4.19.67-2+deb10u1~bpo9+1 
lib/modules/4.19.0-0.bpo.6-686/kernel/drivers/media/usb/hackrf/hackrf.ko
linux-image-4.19.0-4-rt-686-pae 4.19.28-1 
lib/modules/4.19.0-4-rt-686-pae/kernel/drivers/media/tuners/fc2580.ko
linux-image-4.19.0-4-rt-amd64 4.19.28-1 
lib/modules/4.19.0-4-rt-amd64/kernel/drivers/vhost/vringh.ko
linux-image-4.19.0-4-rt-amd64 4.19.28-2 
lib/modules/4.19.0-4-rt-amd64/kernel/drivers/vhost/vringh.ko
linux-image-4.19.0-5-686-pae 4.19.37-2 
lib/modules/4.19.0-5-686-pae/kernel/drivers/bluetooth/ath3k.ko
linux-image-4.19.0-5-686-pae 4.19.37-3 
lib/modules/4.19.0-5-686-pae/kernel/drivers/bluetooth/ath3k.ko
linux-image-4.19.0-5-amd64 4.19.37-1 
lib/modules/4.19.0-5-amd64/kernel/drivers/net/wireless/ralink/rt2x00/rt2500usb.ko
linux-image-4.19.0-5-rt-amd64 4.19.37-5+deb10u2 
lib/modules/4.19.0-5-rt-amd64/kernel/net/ipv4/tcp_hybla.ko
linux-image-4.19.0-17-686 4.19.194-1 
lib/modules/4.19.0-17-686/kernel/drivers/thermal/intel_soc_dts_iosf.ko
linux-image-4.19.0-17-686 4.19.194-2 
lib/modules/4.19.0-17-686/kernel/drivers/thermal/intel_soc_dts_iosf.ko
linux-image-4.19.0-17-686 4.19.194-3 
lib/modules/4.19.0-17-686/kernel/drivers/thermal/intel_soc_dts_iosf.ko
linux-image-4.19.0-17-amd64 4.19.194-1 
lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
linux-image-4.19.0-17-amd64 4.19.194-2 
lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
linux-image-4.19.0-17-amd64 4.19.194-3 
lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
linux-image-4.19.0-18-rt-686-pae 4.19.208-1 
lib/modules/4.19.0-18-rt-686-pae/kernel/drivers/staging/comedi/drivers/jr3_pci.ko
linux-image-4.19.0-19-rt-686-pae 4.19.232-1 
lib/modules/4.19.0-19-rt-686-pae/kernel/fs/sysv/sysv.ko
linux-image-4.19.0-20-amd64 4.19.235-1 
lib/modules/4.19.0-20-amd64/kernel/sound/pci/echoaudio/snd-indigoio.ko
linux-image-4.19.0-20-rt-arm64 4.19.235-1 
lib/modules/4.19.0-20-rt-arm64/kernel/drivers/video/fbdev/arkfb.ko
linux-image-5.2.0-0.bpo.2-amd64 5.2.9-2~bpo10+1 
lib/modules/5.2.0-0.bpo.2-amd64/kernel/drivers/input/keyboard/max7359_keypad.ko
linux-image-5.2.0-2-arm64 5.2.9-1 
lib/modules/5.2.0-2-arm64/kernel/crypto/cast6_generic.ko
linux-image-5.2.0-2-arm64 5.2.9-2 
lib/modules/5.2.0-2-arm64/kernel/crypto/cast6_generic.ko
linux-image-5.2.0-2-rt-686-pae 5.2.9-1 
lib/modules/5.2.0-2-rt-686-pae/kernel/drivers/net/ethernet/intel/ixgb/ixgb.ko
linux-image-5.2.0-2-rt-686-pae 5.2.9-2 
lib/modules/5.2.0-2-rt-686-pae/kernel/drivers/net/ethernet/intel/ixgb/ixgb.ko
linux-image-5.2.0-3-cloud-amd64 5.2.17-1 
lib/modules/5.2.0-3-cloud-amd64/kernel/net/sched/act_skbmod.ko
linux-image-5.3.0-1-amd64 5.3.7-1 
lib/modules/5.3.0-1-amd64/kernel/sound/pci/hda/snd-hda-codec-hdmi.ko
linux-image-5.3.0-2-arm64 5.3.9-3 
lib/modules/5.3.0-2-arm64/kernel/drivers/usb/gadget/function/u_ether.ko
linux-image-5.3.0-2-cloud-amd64 5.3.9-1 
lib/modules/5.3.0-2-cloud-amd64/kernel/fs/nls/nls_koi8-u.ko
linux-image-5.4.0-0.bpo.2-686-pae 5.4.8-1~bpo10+1 
lib/modules/5.4.0-0.bpo.2-686-pae/kernel/drivers/net/phy/aquantia.ko
linux-image-5.4.0-0.bpo.4-rt-arm64 5.4.19-1~bpo10+1 
lib/modules/5.4.0-0.bpo.4-rt-arm64/kernel/drivers/hwmon/lm73.ko
linux-image-5.4.0-3-cloud-amd64 5.4.13-1 
lib/modules/5.4.0-3-cloud-amd64/kernel/net/netfilter/xt_NETMAP.ko
linux-image-5.10.0-0.bpo.9-arm64 5.10.70-1~bpo10+1 
lib/modules/5.10.0-0.bpo.9-arm64/kernel/sound/usb/line6/snd-usb-line6.ko
linux-image-5.10.0-0.bpo.11-rt-686-pae 5.10.92-1~bpo10+1 

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

Control: reassign -1 src:linux-signed-i386 5.10.120+1
Control: severity -1 serious
Control: tag -1 confirmed

On Mon, 13 Jun 2022 01:18:00 -0500 Daniel Lewart  wrote:
> Package: linux-image-5.10.0-15-686-pae
> Version: 5.10.120-1
> Severity: normal
> 
> Debian Kernel Team,
> 
> Encountered on a physical machine and reproduced with QEMU:
> 
> $ sudo modprobe rt61pci
> modprobe: ERROR: could not insert 'rt61pci': Key was rejected by service
> 
> But it works fine on the following:
>   * linux-image-5.10.0-14-686-pae  Verson 5.10.113-1
>   * linux-image-5.10.0-15-amd64    Verson 5.10.120-1
> 
> Here is some more verbosity:
> 
> $ sudo modprobe -v rt61pci
> insmod /lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko
> modprobe: ERROR: could not insert 'rt61pci': Key was rejected by service
> 
> $ sudo modprobe -vv crc-itu-t
> modprobe: INFO: ../libkmod/libkmod.c:365 kmod_set_log_fn() custom logging 
> function 0x47b800 registered
> insmod /lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko
> modprobe: INFO: ../libkmod/libkmod-module.c:892 kmod_module_insert_module() 
> Failed to insert module 
> '/lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko': Key was rejected by 
> service
> modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
> modprobe: INFO: ../libkmod/libkmod.c:332 kmod_unref() context 0x204a2d0 
> released

I can confirm that this module does not load, and this means it has an
invalid signature.  The detached signature present in the source
package seems to be truncated (408 bytes long, where for all other
modules the detached signature is 411 bytes long).

The amd64 kernel package is also affected, but for a different module
(xt_l2tp).

Since the truncated signatures are in the source packages, this is a
problem introduced by the code signing service and will need to be
fixed there.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


signature.asc
Description: This is a digitally signed message part

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Daniel Lewart]

Package: linux-image-5.10.0-15-686-pae
Version: 5.10.120-1
Severity: normal

Debian Kernel Team,

Encountered on a physical machine and reproduced with QEMU:

$ sudo modprobe rt61pci
modprobe: ERROR: could not insert 'rt61pci': Key was rejected by service

But it works fine on the following:
  * linux-image-5.10.0-14-686-pae  Verson 5.10.113-1
  * linux-image-5.10.0-15-amd64Verson 5.10.120-1

Here is some more verbosity:

$ sudo modprobe -v rt61pci
insmod /lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko
modprobe: ERROR: could not insert 'rt61pci': Key was rejected by service

$ sudo modprobe -vv crc-itu-t
modprobe: INFO: ../libkmod/libkmod.c:365 kmod_set_log_fn() custom logging 
function 0x47b800 registered
insmod /lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko
modprobe: INFO: ../libkmod/libkmod-module.c:892 kmod_module_insert_module() 
Failed to insert module 
'/lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko': Key was rejected by 
service
modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
modprobe: INFO: ../libkmod/libkmod.c:332 kmod_unref() context 0x204a2d0 released

Thank you!
Daniel Lewart
Urbana, Illinois