A use-after-free flaw was found in setup_async_work in KSMBD implementation of in-kernel samba server and CIFS in the Linux kernel. This flaw could allow an attacker to crash because of accessing the freed work. CIFS creates some asynchronous works to handle defered lock request, those works will be added to linked list , but when it intializes the reponse header, it marks work as synchronouse without any check, making that linked list contains free work after work was done. Refer: https://lkml.kernel.org/linux-cifs/20230401084951.6085-2-linkinjeon@kernel.org/T/
There was no shipped kernel version were seen affected with this problem. These files are not built in our source code.
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2175634]
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2023-1193
Could you please provide the commit or a link that this CVE refers to? Thanks!
In reply to comment #6: > Could you please provide the commit or a link that this CVE refers to? > Thanks! Forwarding the needinfo to @Rohit.
CIFS creates some asynchronous works to handle defered lock request, those works will be added to linked list , but when it intializes the reponse header, it marks work as synchronouse without any check, making that linked list contains free work after work was done. When client sends a valid samba LOCK request, the calling flow of KSMBD likes below: - `handle_ksmbd_work()` - `__handle_ksmbd_work()` - `__process_request()` - `smb2_lock()` And the crash is as follows: [ 83.655216] ================================================================== [ 83.655588] BUG: KASAN: use-after-free in ksmbd_conn_try_dequeue_request+0x336/0x340 [ 83.656014] Write of size 8 at addr ffff8880158549c0 by task kworker/0:7/375 [ 83.656319] [ 83.656391] CPU: 0 PID: 375 Comm: kworker/0:7 Not tainted 6.0.6 #5 [ 83.656639] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 83.657111] Workqueue: ksmbd-io handle_ksmbd_work [ 83.657348] Call Trace: [ 83.657476] <TASK> [ 83.657629] dump_stack_lvl+0x34/0x48 [ 83.657837] print_report.cold+0x5e/0x5e5 [ 83.658118] ? ksmbd_conn_try_dequeue_request+0x336/0x340 [ 83.658456] kasan_report+0xa3/0x130 [ 83.658654] ? _raw_write_lock_irq+0xd1/0xe0 [ 83.658891] ? ksmbd_conn_try_dequeue_request+0x336/0x340 [ 83.659128] ksmbd_conn_try_dequeue_request+0x336/0x340 [ 83.659348] handle_ksmbd_work+0x52f/0x1080 [ 83.659527] process_one_work+0x721/0x1220 [ 83.659692] worker_thread+0x53a/0x1140 [ 83.659847] ? process_one_work+0x1220/0x1220 [ 83.660020] kthread+0x267/0x300 [ 83.660152] ? kthread_complete_and_exit+0x20/0x20 [ 83.660357] ret_from_fork+0x22/0x30 [ 83.660502] </TASK> We are not aware of a patch fixing this issue.
Fedora does not enable the KSMBD server.
Is https://git.kernel.org/linus/3a9b557f44ea8f216aab515a7db20e23f0eb51b9 the upstream fix for this issue?
In reply to comment #12: > Is https://git.kernel.org/linus/3a9b557f44ea8f216aab515a7db20e23f0eb51b9 the > upstream fix for this issue? Forwarding needinfo to Alex.
In reply to comment #12: > Is https://git.kernel.org/linus/3a9b557f44ea8f216aab515a7db20e23f0eb51b9 the > upstream fix for this issue? Hello Carnil, yes, We have also updated this to our cve page. Thank you.