FS#69174 - kernel NULL pointer dereference while verifying WPA-EAP certificate in iwd

Attached to Project: Arch Linux
Opened by Marcel Krüger (zauguin) - Friday, 01 January 2021, 17:28 GMT
Last edited by Jan Alexander Steffens (heftig) - Saturday, 23 January 2021, 23:50 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:
Since the update to kernel 5.10.3-arch1-1 today, I can no longer connect to my EAP-TTLS based wifi. After algorithm negotiation, I get a kernel NULL pointer dereference in public_key_verify_signature. The certificate on the RADIUS server (https://crt.sh/?id=3713872784) uses a RSA 2048 bit public key.
This leads to iwd being killed.

Additional info:
* package version(s)
- linux 5.10.3.arch1-1 <- The issue appeared after this updating the kernel from previous version 5.9.14.arch1-1
- iwd 1.10-
* config and/or log files etc.
- iwd config:
```
[Security]
EAP-Method=TTLS
EAP-Identity=anonymous
EAP-TTLS-Phase2-Method=Tunneled-PAP
EAP-TTLS-CACert=/etc/ssl/certs/DST_Root_CA_X3.pem
EAP-TTLS-ServerDomainMask=math.hamburg
EAP-TTLS-Phase2-Identity=.....
EAP-TTLS-Phase2-Password=.....
```
- `journalctl -u iwd` and `dmesg` attached

* link to upstream bug report, if any
not created yet.

Steps to reproduce:

Try to connect with a WPA Enterprise network with iwd.
   dmesg (6.1 KiB)
   iwdlog (2.9 KiB)
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Saturday, 23 January 2021, 23:50 GMT
Reason for closing:  Fixed
Additional comments about closing:  linux 5.10.10
Comment by Marcel Krüger (zauguin) - Friday, 01 January 2021, 17:32 GMT
For some reason, the issue does not appear when using wpa_supplicant instead of iwd.
Comment by loqs (loqs) - Friday, 01 January 2021, 19:00 GMT
Looks to be [1] which appears unresolved. wpa_supplicant does not use kernel cryptography.

[1] https://lore.kernel.org/linux-crypto/67250277-7903-2005-b94b-193bce0a3388%40markus-regensburg.de/

Edit:
If you apply test.patch that adds WARN_ON(!sig->pkey_algo); does the WARN_ON trigger?
Comment by Lukas van den Dijssel (LukasvdDijssel) - Saturday, 02 January 2021, 19:17 GMT
@loqs just pointed me to this report, as I have just posted a very similar one, though with some more information:  FS#69184 
Comment by loqs (loqs) - Saturday, 02 January 2021, 19:18 GMT
If you could add the WARN_ON(!sig->pkey_algo); and see if that triggers that would narrow it down a lot.
Comment by Lukas van den Dijssel (LukasvdDijssel) - Saturday, 02 January 2021, 19:48 GMT
I will be recompiling the kernel with the provided patch applied tomorrow, and I'll be back at the Wi-Fi network this Monday. Then I'll report back with my findings.
Comment by Marcel Krüger (zauguin) - Saturday, 02 January 2021, 23:53 GMT
Thank you for looking into this. I tried the kernel with the added WARN_ON and the warning does trigger. Additionally I verified that this also happens with the upstream 5.10.3 tag, so it's certainly not Arch specific. I'll try the current master next.
Comment by Corey Clayton (coreboy) - Friday, 08 January 2021, 19:46 GMT
Hi, I am also running in to this issue after upgrading to 5.10.4-arch2-1

Looking at the above linked thread on the linux-crypto mailing list, it seems that the remains unsolved as of yesterday.
Comment by ketsui (ketsui) - Thursday, 14 January 2021, 04:09 GMT Comment by Joao Fonseca (knaick) - Friday, 15 January 2021, 17:17 GMT
Running iwd 5.9 on linux 5.10.7 and the issue is still occuring. Testing on a Eduroam network which is using EAP-PEAP.

config:

EAP-Method=PEAP
EAP-Identity=anonymous
EAP-CACert=/etc/ssl/certs/ca-certificates.crt
EAP-PEAP-Phase2-Method=MSCHAPV2
EAP-PEAP-Phase2-Identity=user@ua.pt
EAP-Phase2-Password=*****
[Settings]
AutoConnect=true
Comment by loqs (loqs) - Friday, 15 January 2021, 17:25 GMT Comment by Joao Fonseca (knaick) - Friday, 15 January 2021, 17:41 GMT
I will try to recompile the kernel with that patch and check.

Edit: I am compiling it but I probably won't be able to test this patch before monday
Comment by The Backer (backer) - Monday, 18 January 2021, 08:28 GMT
This is "me too" comment. Running into this 5.10.7-arch1. The only workaround right now, for me, is using linux-lts.
   jv-dmesg (6.1 KiB)
Comment by Joao Fonseca (knaick) - Monday, 18 January 2021, 14:48 GMT
@loqs can confirm the patch you provided doesn't correct the issue. Nor does it seem to trigger the warning.
   dmesg (9.9 KiB)
Comment by loqs (loqs) - Monday, 18 January 2021, 16:15 GMT
@knaick you patched with test.patch instead of [1] which should fix the issue.
The dmesg you include shows the warning is triggered on line 3.

[1] https://lore.kernel.org/linux-crypto/20210107092855.76093-1-tianjia.zhang%40linux.alibaba.com/raw
Comment by Joao Fonseca (knaick) - Monday, 18 January 2021, 16:53 GMT
I will try that one.

Comment by Joao Fonseca (knaick) - Monday, 18 January 2021, 17:21 GMT
@loqs just added the correct patch and restarted the computer and it worked.
I have already seen the 5.10.8-arch1 branch appearing when I was making the package . I hope the patch is included...
Comment by loqs (loqs) - Monday, 18 January 2021, 18:33 GMT Comment by Joao Fonseca (knaick) - Monday, 18 January 2021, 21:32 GMT
I just added a comment to the thread. Let's hope it can be added to stable soon enough.

Ps: how do you add links correctly to these bug reports?
Comment by Joao Fonseca (knaick) - Thursday, 21 January 2021, 23:05 GMT
Seems it will be part of the 5.11[1] kernel, received an email today about it.


Edit: [1] actually it was solved in version 5.10.10 of the linux kernel
Comment by loqs (loqs) - Friday, 22 January 2021, 18:36 GMT Comment by Joao Fonseca (knaick) - Saturday, 23 January 2021, 15:45 GMT

Loading...