CVE-2024-40931 – mptcp: ensure snd_una is properly initialized on connect
https://notcve.org/view.php?id=CVE-2024-40931
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: mptcp: ensure snd_una is properly initialized on connect This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snd_una is still left uninitialized. Address the issue explicitly initializing snd_una together with snd_nxt and write_seq. • https://git.kernel.org/stable/c/8fd738049ac3d67a937d36577763b47180aae1ad • CWE-400: Uncontrolled Resource Consumption •
CVE-2024-40930 – wifi: cfg80211: validate HE operation element parsing
https://notcve.org/view.php?id=CVE-2024-40930
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate HE operation element parsing Validate that the HE operation element has the correct length before parsing it. • https://git.kernel.org/stable/c/645f3d85129d8aac3b896ba685fbc20a31c2c036 • CWE-20: Improper Input Validation •
CVE-2024-40929 – wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
https://notcve.org/view.php?id=CVE-2024-40929
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: check n_ssids before accessing the ssids In some versions of cfg80211, the ssids poinet might be a valid one even though n_ssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking n_ssids first. • https://git.kernel.org/stable/c/c1a7515393e403758a684fd0a2372af466675b15 • CWE-125: Out-of-bounds Read •
CVE-2024-40928 – net: ethtool: fix the error condition in ethtool_get_phy_stats_ethtool()
https://notcve.org/view.php?id=CVE-2024-40928
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: net: ethtool: fix the error condition in ethtool_get_phy_stats_ethtool() Clang static checker (scan-build) warning: net/ethtool/ioctl.c:line 2233, column 2 Called function pointer is null (null dereference). Return '-EOPNOTSUPP' when 'ops->get_ethtool_phy_stats' is NULL to fix this typo error. • https://git.kernel.org/stable/c/201ed315f9676809cd5b20a39206e964106d4f27 • CWE-476: NULL Pointer Dereference •
CVE-2024-40927 – xhci: Handle TD clearing for multiple streams case
https://notcve.org/view.php?id=CVE-2024-40927
12 Jul 2024 — 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_... • https://git.kernel.org/stable/c/e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 • CWE-820: Missing Synchronization •
CVE-2024-40926 – drm/nouveau: don't attempt to schedule hpd_work on headless cards
https://notcve.org/view.php?id=CVE-2024-40926
12 Jul 2024 — 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 •
CVE-2024-40925 – block: fix request.queuelist usage in flush
https://notcve.org/view.php?id=CVE-2024-40925
12 Jul 2024 — 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 jus... • https://git.kernel.org/stable/c/81ada09cc25e4bf2de7d2951925fb409338a545d • CWE-665: Improper Initialization •
CVE-2024-40924 – drm/i915/dpt: Make DPT object unshrinkable
https://notcve.org/view.php?id=CVE-2024-40924
12 Jul 2024 — 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 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVE-2024-40923 – vmxnet3: disable rx data ring on dma allocation failure
https://notcve.org/view.php?id=CVE-2024-40923
12 Jul 2024 — 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... • https://git.kernel.org/stable/c/6f4833383e8514ea796d094e05c24889b8997fde • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVE-2024-40922 – io_uring/rsrc: don't lock while !TASK_RUNNING
https://notcve.org/view.php?id=CVE-2024-40922
12 Jul 2024 — 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 [