CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40931 – mptcp: ensure snd_una is properly initialized on connect
https://notcve.org/view.php?id=CVE-2024-40931
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 https://git.kernel.org/stable/c/208cd22ef5e57f82d38ec11c1a1703f9401d6dde https://git.kernel.org/stable/c/7b9c7fc8600b64a86e4b47b2d190bba380267726 https://git.kernel.org/stable/c/f03c46eabb3a67bd2993e237ab5517f00a5f1813 https://git.kernel.org/stable/c/f1f0a46f8bb8890b90ab7194f0a0c8fe2a3fb57f https://git.kernel.org/stable/c/ef473bf1dd7e8dd08bcc04b9e2d1bfed69a0a7ce https://git.kernel.org/stable/c/8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 https://access.redhat.com/security/cve/CVE-2024-40931 • CWE-400: Uncontrolled Resource Consumption •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40929 – wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
https://notcve.org/view.php?id=CVE-2024-40929
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 https://git.kernel.org/stable/c/3c4771091ea8016c8601399078916f722dd8833b https://git.kernel.org/stable/c/f777792952d03bbaf8329fdfa99393a5a33e2640 https://git.kernel.org/stable/c/9e719ae3abad60e245ce248ba3f08148f375a614 https://git.kernel.org/stable/c/29a18d56bd64b95bd10bda4afda512558471382a https://git.kernel.org/stable/c/62e007bdeb91c6879a4652c3426aef1cd9d2937b https://git.kernel.org/stable/c/60d62757df30b74bf397a2847a6db7385c6ee281 https://access.redhat.com/security/cve/CVE-2024-40929 • CWE-125: Out-of-bounds Read •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40928 – net: ethtool: fix the error condition in ethtool_get_phy_stats_ethtool()
https://notcve.org/view.php?id=CVE-2024-40928
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 https://git.kernel.org/stable/c/6548d543a27449a1a3d8079925de93f5764d6f22 https://git.kernel.org/stable/c/92196be82a4eb61813833dc62876fd198ae51ab1 https://git.kernel.org/stable/c/0dcc53abf58d572d34c5313de85f607cd33fc691 https://access.redhat.com/security/cve/CVE-2024-40928 https://bugzilla.redhat.com/show_bug.cgi?id=2297512 • CWE-476: NULL Pointer Dereference •
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: -EPSS: 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 •