Hi,
I've hit this bug also when trying to connect to my office Wifi via IWD.
The pkey_algo is indeed NULL/uninitialized:
As we create the sig here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/crypto/asymmetric_keys/asymmetric_type.c?h=v5.10.5&id=215525639631ade1d67e879
Hi,
Sorry, I just read this email. I will submit the fix patch as soon as
possible. Thanks for reporting.
Best regards,
Tianjia
On 1/7/21 3:27 PM, Tee Hao Wei wrote:
On 2/12/20 8:24 pm, Tobias Markus wrote:
Hi David,
I'm afraid I can't provide an exactly matching disassembly of the functi
On 2/12/20 8:24 pm, Tobias Markus wrote:
> 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 cod
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 net
Tobias Markus 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
Hi,
running 5.10-rc3, I have come across a null pointer dereference.
It occured while trying to connect to a 802.1x/EAP-protected network using iwd.
However, the bug seems to be limited to iwd's usage of the keyctl API
(unrelated to the wireless subsystem).
The bug seems related to the recent ch