CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-40926 – drm/nouveau: don't attempt to schedule hpd_work on headless cards
https://notcve.org/view.php?id=CVE-2024-40926
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: don't attempt to schedule hpd_work on headless cards If the card doesn't have display hardware, hpd_work and hpd_lock are left uninitialized which causes BUG when attempting to schedule hpd_work on runtime PM resume. Fix it by adding headless flag to DRM and skip any hpd if it's set. • https://git.kernel.org/stable/c/ae1aadb1eb8d3cbc52e42bee71d67bd4a71f9f07 https://git.kernel.org/stable/c/227349998e5740f14d531b0f0d704e66b1ed3c2f https://git.kernel.org/stable/c/b96a225377b6602299a03d2ce3c289b68cd41bb7 •
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 •