On Wed, Jan 17, 2018 at 06:36:16AM +0100, Paolo Valente wrote:
>
>
> > Il giorno 17 gen 2018, alle ore 06:16, Eric Biggers <ebiggers3@xxxxxxxxx> ha scritto:
> >
> > Hi Paolo,
> >
> > On Fri, Jan 12, 2018 at 07:06:12AM +0100, Paolo Valente wrote:
> >>
> >>
> >>> Il giorno 11 gen 2018, alle ore 23:37, Arnd Bergmann <arnd@xxxxxxxx> ha scritto:
> >>>
> >>> On Thu, Jan 11, 2018 at 7:29 PM, Paolo Valente <paolo.valente@xxxxxxxxxx> wrote:
> >>>> Hi guys,
> >>>> this is a help request, for a problem that has been driving me crazy
> >>>> all day long, without any success :(
> >>>>
> >>>> I've compiled a 4.15-rc7 custom kernel on a freshly-installed Fedora
> >>>> 27, using the usual "make ; make modules_install ; make install"
> >>>> procedure. No error reported while building. But at boot the
> >>>> kernel immediately fails as follows, apparently while loading/parsing
> >>>> an X.509 certificate:
> >>>
> >>> The BUG_ON() you hit is this one in public_key_verify_signature():
> >>>
> >>> BUG_ON(!sig->digest);
> >>>
> >>> There was a patch series by Eric Biggers that touched these files to
> >>> add some fixes
> >>> after v4.15-rc1. I'm not runnig that code myself, but it sounds like
> >>> a real regression,
> >>> so I'm adding Eric (to look at the code), the corresponding mailing
> >>> list and Thorsten
> >>> (for regression tracking) to Cc.
> >>>
> >>> x509_cert_parse() allocates the 'cert->sig' structure, and calls
> >>> x509_get_sig_params(),
> >>> which may or may not allocate a digest. It returns with
> >>> cert->unsupported_sig=true
> >>> in case it fails to allocate a digest for some reason (crypto_alloc_shash failed
> >>> or no sig->hash_algo).
> >>>
> >>> The full set of Eric's patches is
> >>>
> >>> 54c1fb39fe04 X.509: fix comparisons of ->pkey_algo
> >>> 18026d866801 KEYS: reject NULL restriction string when type is specified
> >>> 3d1f0255426a security: keys: remove redundant assignment to key_ref
> >>> aa3300362060 X.509: use crypto_shash_digest()
> >>> 72f9a07b6bfa KEYS: be careful with error codes in public_key_verify_signature()
> >>> a80745a6de51 pkcs7: use crypto_shash_digest()
> >>> 7204eb8590c7 pkcs7: fix check for self-signed certificate
> >>> 8ecb506d3476 pkcs7: return correct error code if pkcs7_check_authattrs() fails
> >>> 8dfd2f22d3bf 509: fix printing uninitialized stack memory when OID is empty
> >>> 47e0a208fb9d X.509: fix buffer overflow detection in sprint_oid()
> >>> 0f30cbea005b X.509: reject invalid BIT STRING for subjectPublicKey
> >>> 81a7be2cd69b ASN.1: check for error from ASN1_OP_END__ACT actions
> >>> e0058f3a874e ASN.1: fix out-of-bounds read when parsing indefinite length item
> >>> 4dca6ea1d943 KEYS: add missing permission check for request_key() destination
> >>> a2d8737d5c78 KEYS: remove unnecessary get/put of explicit dest_keyring
> >>>
> >>> and it's based on -rc2. If you want to do a quicker bisection, I'd
> >>> suggest you try
> >>> 4.15-rc2 and 54c1fb39fe04 to start with.
> >>>
> >>
> >> Thank you very much Arnd. Fortunately, for the task I'm performing, a
> >> 4.14 will do too. And I'm under pressure to finally finish this task.
> >> Yet, even before I finish with this task, I'm willing to do any test
> >> that the guys you added may want me to do. And, if more useful for
> >> the community, ok for me to switch to the most appropriate public
> >> mailing lists.
> >>
> >
> > Have you managed to bisect this yet? I'm not seeing how my changes could have
> > caused this, but it does seem there may be an existing bug where this BUG() can
> > be hit if a certificate's signature uses a hash algorithm that is not built into
> > the kernel. To verify whether that is happening can you try adding:
> >
> > diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c
> > index 9338b4558cdc..f1804640445a 100644
> > --- a/crypto/asymmetric_keys/x509_public_key.c
> > +++ b/crypto/asymmetric_keys/x509_public_key.c
> > @@ -58,6 +58,8 @@ int x509_get_sig_params(struct x509_certificate *cert)
> > tfm = crypto_alloc_shash(sig->hash_algo, 0, 0);
> > if (IS_ERR(tfm)) {
> > if (PTR_ERR(tfm) == -ENOENT) {
> > + pr_err("Hash algorithm %s not supported by crypto API\n",
> > + sig->hash_algo);
> > cert->unsupported_sig = true;
> > return 0;
> > }
> >
> > If the pr_err() is hit then check the status of the corresponding CONFIG_CRYPTO_
> > option in your .config, for example CONFIG_CRYPTO_SHA256 if the algorithm is
> > "sha256".
> >
>
> Hi Eric,
> in the meantime I have moved to rc8, and the problem has disappeared.
> Does this ring any bell? Otherwise, I'll retry with rc7 after adding
> your error message.
>
> Thanks,
> Paolo
>
No, it doesn't ring a bell. Is it possible you changed your kernel config
between rc7 and rc8?
