CVSS: 6.1EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40927 – xhci: Handle TD clearing for multiple streams case
https://notcve.org/view.php?id=CVE-2024-40927
In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. • https://git.kernel.org/stable/c/e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 https://git.kernel.org/stable/c/26460c1afa311524f588e288a4941432f0de6228 https://git.kernel.org/stable/c/633f72cb6124ecda97b641fbc119340bd88d51a9 https://git.kernel.org/stable/c/949be4ec5835e0ccb3e2a8ab0e46179cb5512518 https://git.kernel.org/stable/c/61593dc413c3655e4328a351555235bc3089486a https://git.kernel.org/stable/c/5ceac4402f5d975e5a01c806438eb4e554771577 https://access.redhat.com/security/cve/CVE-2024-40927 https://bugzilla.redhat.com/show_bug.cgi?id=2297511 • CWE-820: Missing Synchronization •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40925 – block: fix request.queuelist usage in flush
https://notcve.org/view.php?id=CVE-2024-40925
In the Linux kernel, the following vulnerability has been resolved: block: fix request.queuelist usage in flush Friedrich Weber reported a kernel crash problem and bisected to commit 81ada09cc25e ("blk-flush: reuse rq queuelist in flush state machine"). The root cause is that we use "list_move_tail(&rq->queuelist, pending)" in the PREFLUSH/POSTFLUSH sequences. But rq->queuelist.next == xxx since it's popped out from plug->cached_rq in __blk_mq_alloc_requests_batch(). We don't initialize its queuelist just for this first request, although the queuelist of all later popped requests will be initialized. Fix it by changing to use "list_add_tail(&rq->queuelist, pending)" so rq->queuelist doesn't need to be initialized. It should be ok since rq can't be on any list when PREFLUSH or POSTFLUSH, has no move actually. Please note the commit 81ada09cc25e ("blk-flush: reuse rq queuelist in flush state machine") also has another requirement that no drivers would touch rq->queuelist after blk_mq_end_request() since we will reuse it to add rq to the post-flush pending list in POSTFLUSH. If this is not true, we will have to revert that commit IMHO. This updated version adds "list_del_init(&rq->queuelist)" in flush rq callback since the dm layer may submit request of a weird invalid format (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), which causes double list_add if without this "list_del_init(&rq->queuelist)". The weird invalid format problem should be fixed in dm layer. • https://git.kernel.org/stable/c/81ada09cc25e4bf2de7d2951925fb409338a545d https://git.kernel.org/stable/c/fe1e395563ccb051e9dbd8fa99859f5caaad2e71 https://git.kernel.org/stable/c/87907bd69721a8506618a954d41a1de3040e88aa https://git.kernel.org/stable/c/d0321c812d89c5910d8da8e4b10c891c6b96ff70 https://access.redhat.com/security/cve/CVE-2024-40925 https://bugzilla.redhat.com/show_bug.cgi?id=2297509 • CWE-665: Improper Initialization •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40924 – drm/i915/dpt: Make DPT object unshrinkable
https://notcve.org/view.php?id=CVE-2024-40924
In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Make DPT object unshrinkable In some scenarios, the DPT object gets shrunk but the actual framebuffer did not and thus its still there on the DPT's vm->bound_list. Then it tries to rewrite the PTEs via a stale CPU mapping. This causes panic. [vsyrjala: Add TODO comment] (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c) • https://git.kernel.org/stable/c/0dc987b699ce4266450d407d6d79d41eab88c5d0 https://git.kernel.org/stable/c/327280149066f0e5f2e50356b5823f76dabfe86e https://git.kernel.org/stable/c/7a9883be3b98673333eec65c4a21cc18e60292eb https://git.kernel.org/stable/c/a2552020fb714ff357182c3c179abfac2289f84d https://git.kernel.org/stable/c/43e2b37e2ab660c3565d4cff27922bc70e79c3f1 https://access.redhat.com/security/cve/CVE-2024-40924 https://bugzilla.redhat.com/show_bug.cgi?id=2297508 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40923 – vmxnet3: disable rx data ring on dma allocation failure
https://notcve.org/view.php?id=CVE-2024-40923
In the Linux kernel, the following vulnerability has been resolved: vmxnet3: disable rx data ring on dma allocation failure When vmxnet3_rq_create() fails to allocate memory for rq->data_ring.base, the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset rq->data_ring.desc_size for the data ring that failed, which presumably causes the hypervisor to reference it on packet reception. To fix this bug, rq->data_ring.desc_size needs to be set to 0 to tell the hypervisor to disable this feature. [ 95.436876] kernel BUG at net/core/skbuff.c:207! [ 95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1 [ 95.441558] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018 [ 95.443481] RIP: 0010:skb_panic+0x4d/0x4f [ 95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50 ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9 ff <0f> 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24 [ 95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246 [ 95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f [ 95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f [ 95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60 [ 95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000 [ 95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0 [ 95.455682] FS: 0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000 [ 95.457178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0 [ 95.459791] Call Trace: [ 95.460515] <IRQ> [ 95.461180] ? __die_body.cold+0x19/0x27 [ 95.462150] ? die+0x2e/0x50 [ 95.462976] ? • https://git.kernel.org/stable/c/6f4833383e8514ea796d094e05c24889b8997fde https://git.kernel.org/stable/c/9ee14af24e67ef170108db547f7d1f701b3f2bc5 https://git.kernel.org/stable/c/aa116ae9d169e28b692292460aed27fc44f4a017 https://git.kernel.org/stable/c/ffbe335b8d471f79b259e950cb20999700670456 https://access.redhat.com/security/cve/CVE-2024-40923 https://bugzilla.redhat.com/show_bug.cgi?id=2297507 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40922 – io_uring/rsrc: don't lock while !TASK_RUNNING
https://notcve.org/view.php?id=CVE-2024-40922
In the Linux kernel, the following vulnerability has been resolved: io_uring/rsrc: don't lock while !TASK_RUNNING There is a report of io_rsrc_ref_quiesce() locking a mutex while not TASK_RUNNING, which is due to forgetting restoring the state back after io_run_task_work_sig() and attempts to break out of the waiting loop. do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff815d2494>] prepare_to_wait+0xa4/0x380 kernel/sched/wait.c:237 WARNING: CPU: 2 PID: 397056 at kernel/sched/core.c:10099 __might_sleep+0x114/0x160 kernel/sched/core.c:10099 RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099 Call Trace: <TASK> __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0xb4/0x940 kernel/locking/mutex.c:752 io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253 io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799 __io_uring_register io_uring/register.c:424 [inline] __do_sys_io_uring_register+0x5b9/0x2400 io_uring/register.c:613 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 • https://git.kernel.org/stable/c/4ea15b56f0810f0d8795d475db1bb74b3a7c1b2f https://git.kernel.org/stable/c/0c9df3df0c888d9ec8d11a68474a4aa04d371cff https://git.kernel.org/stable/c/4429c6c77e176a4c5aa7a3bbd1632f9fc0582518 https://git.kernel.org/stable/c/54559642b96116b45e4b5ca7fd9f7835b8561272 https://access.redhat.com/security/cve/CVE-2024-40922 https://bugzilla.redhat.com/show_bug.cgi?id=2297506 • CWE-413: Improper Resource Locking •