Hi David,

I'm afraid I can't provide an exactly matching disassembly of the function since I've since updated to newer -rc kernels.
Another debugging hurdle is that the specific kernel code path seems to be triggered by a very specific iwd code path that iwd only uses for 802.1X/EAP-secured networks, and I simply wasn't near any EAP-secured networks in the last few weeks.
I've tried creating a reproducer using a bash script calling various keyctl commands but to no success.

However, I can provide you a disassembly using my current -rc5 kernel that should correspond to the code path in question along with some observations.
Note that I inserted a BUG_ON right before the if statement for testing (that I couldn't get it to trigger yet since I wasn't near any EAP networks in the last weeks).
With the BUG_ON, lines 359-364 in crypto/asymmetric_keys/public_key.c look like this:
    BUG_ON(!sig->pkey_algo);
    if (strcmp(sig->pkey_algo, "sm2") == 0 && sig->data_size) {
        ret = cert_sig_digest_update(sig, tfm);
        if (ret)
            goto error_free_key;
    }

The relevant disassembly (I've attached the full disassembly):
<...>
359	    BUG_ON(!sig->pkey_algo);
   0xffffffff8158cee9 <+377>:	mov    0x30(%rbp),%rsi
   0xffffffff8158ceed <+381>:	test   %rsi,%rsi
   0xffffffff8158cef0 <+384>:	je     0xffffffff8158d11f <public_key_verify_signature+943>
   0xffffffff8158d11f <+943>:	ud2

360		if (strcmp(sig->pkey_algo, "sm2") == 0 && sig->data_size) {
   0xffffffff8158cef6 <+390>:	mov    $0xffffffff82c427b0,%rdi
   0xffffffff8158cefd <+397>:	mov    $0x4,%ecx
   0xffffffff8158cf02 <+402>:	repz cmpsb %es:(%rdi),%ds:(%rsi)
   0xffffffff8158cf04 <+404>:	seta   %al
   0xffffffff8158cf07 <+407>:	sbb    $0x0,%al
   0xffffffff8158cf09 <+409>:	test   %al,%al
   0xffffffff8158cf0b <+411>:	jne    0xffffffff8158cf18 <public_key_verify_signature+424>
   0xffffffff8158cf0d <+413>:	mov    0x50(%rbp),%eax
   0xffffffff8158cf10 <+416>:	test   %eax,%eax
   0xffffffff8158cf12 <+418>:	jne    0xffffffff8158d0df <public_key_verify_signature+879>
<...>

Some observations:
1. From the Oops report, rsi was zero and seems to be the source of the null pointer.
2. Interpreting the BUG_ON disassembly, rsi is apparently set to sig->pkey_algo.
3. If I recall correctly from the analysis I did right after the Oops, public_key_verify_signature+402 should be the instruction that triggered the Oops. It corresponds to the strcmp.

In conclusion, my hypothesis would be that for some reason sig->pkey_algo is a null pointer.
This seems plausible since the strcmp would be the first line to actually touch sig->pkey_algo in that function.
Take all this with a grain of salt because in theory GCC could have shuffled stuff around since I introduced the BUG_ON.

I would love to debug this further, but I'm in dire need of a simpler test case (other than finding another EAP-secured network). If you or anyone could point me to a simple program that uses the public key infrastructure, it might be easier to trigger the Oops again.

Kind Regards,
Tobias

David Howells wrote:
> Tobias Markus <tobias@markus-regensburg.de> wrote:
> 
>> kernel: RIP: 0010:public_key_verify_signature+0x189/0x3f0
> 
> Is it possible for you to provide a disassembly of this function from the
> kernel you were using?  For this to occur on that line, it appears that sig
> would need to be NULL - but that should trip an assertion at the top of the
> function - or a very small number (which could be RCX, R09 or R11).
> 
> Thanks,
> David
>