CVSS: -EPSS: 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 •
CVSS: -EPSS: 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 •
CVSS: -EPSS: 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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40921 – net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state
https://notcve.org/view.php?id=CVE-2024-40921
In the Linux kernel, the following vulnerability has been resolved: net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state Pass the already obtained vlan group pointer to br_mst_vlan_set_state() instead of dereferencing it again. Each caller has already correctly dereferenced it for their context. This change is required for the following suspicious RCU dereference fix. No functional changes intended. • https://git.kernel.org/stable/c/8ca9a750fc711911ef616ceb627d07357b04545e https://git.kernel.org/stable/c/4488617e5e995a09abe4d81add5fb165674edb59 https://git.kernel.org/stable/c/e43dd2b1ec746e105b7db5f9ad6ef14685a615a4 https://git.kernel.org/stable/c/a2b01e65d9ba8af2bb086d3b7288ca53a07249ac https://git.kernel.org/stable/c/09f4337c27f5bdeb8646a6db91488cc2f7d537ff https://git.kernel.org/stable/c/a6cc9e9a651b9861efa068c164ee62dfba68c6ca https://git.kernel.org/stable/c/d2dc02775fc0c4eacaee833a0637e5958884a8e5 https://git.kernel.org/stable/c/36c92936e868601fa1f43da6758cf5580 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40920 – net: bridge: mst: fix suspicious rcu usage in br_mst_set_state
https://notcve.org/view.php?id=CVE-2024-40920
In the Linux kernel, the following vulnerability has been resolved: net: bridge: mst: fix suspicious rcu usage in br_mst_set_state I converted br_mst_set_state to RCU to avoid a vlan use-after-free but forgot to change the vlan group dereference helper. Switch to vlan group RCU deref helper to fix the suspicious rcu usage warning. • https://git.kernel.org/stable/c/8ca9a750fc711911ef616ceb627d07357b04545e https://git.kernel.org/stable/c/4488617e5e995a09abe4d81add5fb165674edb59 https://git.kernel.org/stable/c/e43dd2b1ec746e105b7db5f9ad6ef14685a615a4 https://git.kernel.org/stable/c/a2b01e65d9ba8af2bb086d3b7288ca53a07249ac https://git.kernel.org/stable/c/caaa2129784a04dcade0ea92c12e6ff90bbd23d8 https://git.kernel.org/stable/c/7caefa2771722e65496d85b62e1dc4442b7d1345 https://git.kernel.org/stable/c/406bfc04b01ee47e4c626f77ecc7d9f85135b166 https://git.kernel.org/stable/c/546ceb1dfdac866648ec959cbc71d9525 •