Bugzilla – Bug 1210685
VUL-0: CVE-2023-33203: kernel: Use after free bug in emac_remove due to race condition
Last modified: 2023-05-19 07:59:45 UTC
n emac_probe, &adpt->work_thread is bound with emac_work_thread. Then it will be started by timeout handler emac_tx_timeout or a IRQ handler emac_isr. If we remove the driver which will call emac_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows: Fix it by finishing the work before cleanup in the emac_remove and disable timeout response. CPU0 CPU1 |emac_work_thread emac_remove | free_netdev | kfree(netdev); | |emac_reinit_locked |emac_mac_down |//use netdev This bug has been submitted to upstream and got fixed in [1] [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=6b6bc5b8bd2d This is a bug reported by me and has been merged in following releases: Linux kernel 4.14 Linux kernel 4.19 Linux kernel 5.4 Linux kernel 5.10 Linux kernel 5.15 Linux kernel 6.1 Linux kernel 6.2 Also,this has been fixed in SUSE [2] Could you please assign CVE for this? [2] https://lists.suse.com/pipermail/sle-security-updates/2023-April/014436.html
Here is the description: The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/net/ethernet/qualcomm/emac/emac.c if a physically proximate attacker unplugs a device. Credit Information: Zheng Wang(@xmzyshypnc), Zhuorao Yang(@A1ex), Yang Hu(@BlueSheep) and Zong Cao(@P1umer)
what kind of device is this? usb?
(not sure how this device could be removed? I see a openfirmware variant?=
(In reply to Marcus Meissner from comment #2) > what kind of device is this? usb? Hi, Thanks for your reply. This issue is found by static analysis so there's no PoC. The device is Qualcomm microchip after reading the source code.
(In reply to Marcus Meissner from comment #3) > (not sure how this device could be removed? I see a openfirmware variant?= I'm also not sure about that. If we cannot physically remove it, the issue might be hard to trigger.
Friendly ping
i reviewed again, I would currently assume the device is removable. -> i requested a CVE from Mitre just now.
(In reply to Marcus Meissner from comment #7) > i reviewed again, I would currently assume the device is removable. > > -> i requested a CVE from Mitre just now. Hi Marcus, Thanks for your effort. I found this bug has been assigned with a CVE number which is CVE-2023-2483. Best regards, Zheng
You seem to have filed the same request with Red Hat without mentioning it leading to duplicate effort. PLease mention in next requests if you requested CVEs from multiple people and from who. *** This bug has been marked as a duplicate of bug 1211037 ***
(In reply to Marcus Meissner from comment #9) > You seem to have filed the same request with Red Hat without mentioning it > leading to duplicate effort. > > PLease mention in next requests if you requested CVEs from multiple people > and from who. > > *** This bug has been marked as a duplicate of bug 1211037 *** Sorry for my mistake. It wasted your precious time and I promise that would not happen again. Thanks, Zheng
Besides, I have a question that if I submitted a bug to Redhat, but they didn't respond to it for a long time (about a month), Can I report it to SUSE? Apprecaite for you reply. Best regards, Zheng
You can report it to us, no problem. We would just appreciate to know if you also submitted it to red hat, and cross-share references. The main problem is duplicate assignments of CVEs, which needs to be avoided.
(In reply to Marcus Meissner from comment #12) > You can report it to us, no problem. We would just appreciate to know if you > also submitted it to red hat, and cross-share references. > > The main problem is duplicate assignments of CVEs, which needs to be avoided. Thanks for your kind explaination. Got it :)