On Fri, Jun 2, 2023 at 10:41 AM Roberto Sassu roberto.sassu@huaweicloud.com wrote:
sorry for this unusual procedure of me requesting a patch to be pulled. I asked for several months the maintainers (David: asymmetric keys, Jarkko: key subsystem) to pick my patch but without any luck.
Hmm.
The patch behind that tag looks sane to me, but this is not code I am hugely familiar with.
Who is the caller that passes in the public_key_signature data on the stack to public_key_verify_signature()? This may well be the right point to move it away from the stack in order to have a valid sg-list, but even if this patch is all good, it would be nice to have the call chain documented as part of the commit message.
I signed the tag, but probably it would not matter, since my key is not among your trusted keys.
It does matter - I do pull from people even without full chains, I just end up being a lot more careful, and I still want to see the signature for any future reference...
DavidH, Herbert, please comment:
https://github.com/robertosassu/linux.git tags/asym-keys-fix-for-linus-v6.4-rc5
basically public_key_verify_signature() is passed that
const struct public_key_signature *sig
as an argument, and currently does
sg_init_table(src_sg, 2); sg_set_buf(&src_sg[0], sig->s, sig->s_size); sg_set_buf(&src_sg[1], sig->digest, sig->digest_size);
on it which is *not* ok if the s->s and s->digest points to stack data that ends up not dma'able because of a virtually mapped stack.
The patch re-uses the allocation it already does for the key data, and it seems sane.
But again, this is not code I look at normally, so...
Linus