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

[Ansgar <ansgar@debian.org>]

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