[lts-9.2] tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux #269
Conversation
jira VULN-676 cve-pre CVE-2023-6546 commit-author Zhenguo Zhao <[email protected]> commit 5b87686 As requester,because n_gsm has no uevent report for application,the application can't know dlci connect or disconnect. The application will control every dlcl dev by uevent,when application receive gsmtty0 dev remove uevent,it will close mux function,and change to normal mode. Example: Before modify: gsmld receive DLC0 DISC,no event report to application gsmld receive DLC1 SABM,no event report to application gsmld receive DLC1 DISC,no event report to application After modify: Receive DLC0 DISC,report "/devices/virtual/tty/gsmtty0" remove uevent Receive DLC1 SABM,report "/devices/virtual/tty/gsmtty1" add uevent Receive DLC1 DISC,report "/devices/virtual/tty/gsmtty1" remove uevent Signed-off-by: Zhenguo Zhao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 5b87686) Signed-off-by: David Gomez <[email protected]>
jira VULN-676 cve-pre CVE-2023-6546 commit-author Daniel Starke <[email protected]> commit aa371e9 n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.8.2 states that both sides will revert to the non-multiplexed mode via a close-down message (CLD). The usual program flow is as following: - start multiplex mode by sending AT+CMUX to the mobile - establish the control channel (DLCI 0) - establish user channels (DLCI >0) - terminate user channels - send close-down message (CLD) - revert to AT protocol (i.e. leave multiplexed mode) The AT protocol is out of scope of the n_gsm driver. However, gsm_disconnect() sends CLD if gsm_config() detects that the requested parameters require the mux protocol to restart. The next immediate action is to start the mux protocol by opening DLCI 0 again. Any responder side which handles CLD commands correctly forces us to fail at this point because AT+CMUX needs to be sent to the mobile to start the mux again. Therefore, remove the CLD command in this phase and keep both sides in multiplexed mode. Remove the gsm_disconnect() function as it become unnecessary and merge the remaining parts into gsm_cleanup_mux() to handle the termination order and locking correctly. Fixes: 71e0779 ("tty: n_gsm: do not send/receive in ldisc close path") Cc: [email protected] Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit aa371e9) Signed-off-by: David Gomez <[email protected]>
jira VULN-676 cve-pre CVE-2023-6546 commit-author Daniel Starke <[email protected]> commit deefc58 The current DLCI release order starts with the control channel followed by the user channels. Reverse this order to keep the control channel open until all user channels have been released. Fixes: e1eaea4 ("tty: n_gsm line discipline") Cc: [email protected] Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit deefc58) Signed-off-by: David Gomez <[email protected]>
jira VULN-676 cve-pre CVE-2023-6546 commit-author Chaoyuan Peng <[email protected]> commit 9b9c819 In gsm_cleanup_mux() the 'gsm->dlci' pointer was not cleaned properly, leaving it a dangling pointer after gsm_dlci_release. This leads to use-after-free where 'gsm->dlci[0]' are freed and accessed by the subsequent gsm_cleanup_mux(). Such is the case in the following call trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 print_address_description+0x63/0x3b0 mm/kasan/report.c:248 __kasan_report mm/kasan/report.c:434 [inline] kasan_report+0x16b/0x1c0 mm/kasan/report.c:451 gsm_cleanup_mux+0x76a/0x850 drivers/tty/n_gsm.c:2397 gsm_config drivers/tty/n_gsm.c:2653 [inline] gsmld_ioctl+0xaae/0x15b0 drivers/tty/n_gsm.c:2986 tty_ioctl+0x8ff/0xc50 drivers/tty/tty_io.c:2816 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl+0xf1/0x160 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x61/0xcb </TASK> Allocated by task 3501: kasan_save_stack mm/kasan/common.c:38 [inline] kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:434 [inline] ____kasan_kmalloc+0xba/0xf0 mm/kasan/common.c:513 kasan_kmalloc include/linux/kasan.h:264 [inline] kmem_cache_alloc_trace+0x143/0x290 mm/slub.c:3247 kmalloc include/linux/slab.h:591 [inline] kzalloc include/linux/slab.h:721 [inline] gsm_dlci_alloc+0x53/0x3a0 drivers/tty/n_gsm.c:1932 gsm_activate_mux+0x1c/0x330 drivers/tty/n_gsm.c:2438 gsm_config drivers/tty/n_gsm.c:2677 [inline] gsmld_ioctl+0xd46/0x15b0 drivers/tty/n_gsm.c:2986 tty_ioctl+0x8ff/0xc50 drivers/tty/tty_io.c:2816 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl+0xf1/0x160 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x61/0xcb Freed by task 3501: kasan_save_stack mm/kasan/common.c:38 [inline] kasan_set_track+0x4b/0x80 mm/kasan/common.c:46 kasan_set_free_info+0x1f/0x40 mm/kasan/generic.c:360 ____kasan_slab_free+0xd8/0x120 mm/kasan/common.c:366 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_hook mm/slub.c:1705 [inline] slab_free_freelist_hook+0xdd/0x160 mm/slub.c:1731 slab_free mm/slub.c:3499 [inline] kfree+0xf1/0x270 mm/slub.c:4559 dlci_put drivers/tty/n_gsm.c:1988 [inline] gsm_dlci_release drivers/tty/n_gsm.c:2021 [inline] gsm_cleanup_mux+0x574/0x850 drivers/tty/n_gsm.c:2415 gsm_config drivers/tty/n_gsm.c:2653 [inline] gsmld_ioctl+0xaae/0x15b0 drivers/tty/n_gsm.c:2986 tty_ioctl+0x8ff/0xc50 drivers/tty/tty_io.c:2816 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl+0xf1/0x160 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x61/0xcb Fixes: aa371e9 ("tty: n_gsm: fix restart handling via CLD command") Signed-off-by: Chaoyuan Peng <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 9b9c819) Signed-off-by: David Gomez <[email protected]>
jira VULN-676 cve CVE-2023-6546 commit-author Yi Yang <[email protected]> commit 3c4f833 In commit 9b9c819 ("tty: n_gsm: fix UAF in gsm_cleanup_mux"), the UAF problem is not completely fixed. There is a race condition in gsm_cleanup_mux(), which caused this UAF. The UAF problem is triggered by the following race: task[5046] task[5054] ----------------------- ----------------------- gsm_cleanup_mux(); dlci = gsm->dlci[0]; mutex_lock(&gsm->mutex); gsm_cleanup_mux(); dlci = gsm->dlci[0]; //Didn't take the lock gsm_dlci_release(gsm->dlci[i]); gsm->dlci[i] = NULL; mutex_unlock(&gsm->mutex); mutex_lock(&gsm->mutex); dlci->dead = true; //UAF Fix it by assigning values after mutex_lock(). Link: https://syzkaller.appspot.com/text?tag=CrashReport&x=176188b5a80000 Cc: stable <[email protected]> Fixes: 9b9c819 ("tty: n_gsm: fix UAF in gsm_cleanup_mux") Fixes: aa371e9 ("tty: n_gsm: fix restart handling via CLD command") Signed-off-by: Yi Yang <[email protected]> Co-developed-by: Qiumiao Zhang <[email protected]> Signed-off-by: Qiumiao Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 3c4f833) Signed-off-by: David Gomez <[email protected]>
|
More information for reviewers: The original commit needed for this CVE: torvalds/linux@3c4f833 Looking at the commit it says it fixes two other commits: Attempted to backport those commits but ran into issues which required more commits so the final commit chain in total looks like the below: This is needed for the following commit This is needed by the commit that fixes the CVE that fixes this commit This is need for the following commit This is needed by the commit that fixes the CVE that fixes this commit This commit fixes the CVE which fixes 2 of the above commits |
There was a problem hiding this comment.
So this is the fix referenced in the CVE:
torvalds/linux@3c4f833
The above fixes this:
torvalds/linux@9b9c819
The above fixes this:
torvalds/linux@aa371e9
And that commit isn't in ciqlts9_2. Are we trying to fix something that isn't an issue in this branch?
Ah so actually it's possible that ciqlts9_2 is unaffected then by this CVE? |
It looks that way to me. If you look at the RH data in the ticket it references 9.2 Extended Support kernels, but not the original 9.2 kernel which jives with what I see in the commit history of ciqlts9_2. Perhaps they did cherry pick aa371e9 in the 9.2 Extended Support kernels but not the OG 9.2 kernel. |
|
Its possible, we need to see if any of the upstream shas that you did This is going to be a time consuming set of CVEs because it looks like they say their vulnerable everywhere |
For more information see ticket referenced below
jira VULN-676
cve CVE-2023-6546
Build Log
Testing
5.14.0-284.30.1.el9_2.92ciq_lts.5.2.x86_64.log
5.14.0-dgomez-ciqlts9_2_VULN-676-f9fa8ba6f4ea.log