CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50082 – blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race
https://notcve.org/view.php?id=CVE-2024-50082
In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. • https://git.kernel.org/stable/c/38cfb5a45ee013bfab5d1ae4c4738815e744b440 https://git.kernel.org/stable/c/d04b72c9ef2b0689bfc1057d21c4aeed087c329f https://git.kernel.org/stable/c/3bc6d0f8b70a9101456cf02ab99acb75254e1852 https://git.kernel.org/stable/c/455a469758e57a6fe070e3e342db12e4a629e0eb https://git.kernel.org/stable/c/b5e900a3612b69423a0e1b0ab67841a1fb4af80f https://git.kernel.org/stable/c/4c5b123ab289767afe940389dbb963c5c05e594e https://git.kernel.org/stable/c/04f283fc16c8d5db641b6bffd2d8310aa7eccebc https://git.kernel.org/stable/c/e972b08b91ef48488bae9789f03cfedb1 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50078 – Bluetooth: Call iso_exit() on module unload
https://notcve.org/view.php?id=CVE-2024-50078
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ... • https://git.kernel.org/stable/c/ccf74f2390d60a2f9a75ef496d2564abb478f46a https://git.kernel.org/stable/c/4af7ba39a1a02e16ee8cd0d3b6c6657f51b8ad7a https://git.kernel.org/stable/c/05f84d86169b2ebac185c5736a256823d42c425b https://git.kernel.org/stable/c/f905a7d95091e0d2605a3a1a157a9351f09ab2e1 https://git.kernel.org/stable/c/d458cd1221e9e56da3b2cc5518ad3225caa91f20 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50077 – Bluetooth: ISO: Fix multiple init when debugfs is disabled
https://notcve.org/view.php?id=CVE-2024-50077
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false. • https://git.kernel.org/stable/c/ccf74f2390d60a2f9a75ef496d2564abb478f46a https://git.kernel.org/stable/c/fa4b832c5a6ec35023a1b997cf658c436619c752 https://git.kernel.org/stable/c/8fb8e912afb4c47dec12ea9a5853e7a8db95816f https://git.kernel.org/stable/c/adf1b179c2ff8073c24bf87e5a605fcc5a09798b https://git.kernel.org/stable/c/a9b7b535ba192c6b77e6c15a4c82d853163eab8c •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50076 – vt: prevent kernel-infoleak in con_font_get()
https://notcve.org/view.php?id=CVE-2024-50076
In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system. • https://git.kernel.org/stable/c/05e2600cb0a4d73b0779cf29512819616252aeeb https://git.kernel.org/stable/c/efc67cee700b89ffbdb74a0603a083ec1290ae31 https://git.kernel.org/stable/c/dc794e878e6d79f75205be456b1042a289c5759d https://git.kernel.org/stable/c/1e5a17dc77d8a8bbe67040b32e2ef755901aba44 https://git.kernel.org/stable/c/b3959d5eca136e0588f9af3867b34032160cb826 https://git.kernel.org/stable/c/23c4cb8a56978e5b1baa171d42e616e316c2039d https://git.kernel.org/stable/c/dc2d5f02636c7587bdd6d1f60fc59c55860b00a4 https://git.kernel.org/stable/c/adb1f312f38f0d2c928ceaff089262798 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50075 – xhci: tegra: fix checked USB2 port number
https://notcve.org/view.php?id=CVE-2024-50075
In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100) • https://git.kernel.org/stable/c/a30951d31b250bf3479c00e93646b6cc6fb42a56 https://git.kernel.org/stable/c/9c696bf4ab54c7cec81221887564305f0ceeac0a https://git.kernel.org/stable/c/c46555f14b71f95a447f5d49fc3f1f80a1472da2 https://git.kernel.org/stable/c/7d381137cb6ecf558ef6698c7730ddd482d4c8f2 •