CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-45010 – mptcp: pm: only mark 'subflow' endp as available
https://notcve.org/view.php?id=CVE-2024-45010
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only mark 'subflow' endp as available Adding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0) ... before decrementing the local_addr_used counter helped to find a bug when running the "remove single address" subtest from the mptcp_join.sh selftests. Removing a 'signal' endpoint will trigger the removal of all subflows linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used counter, which is wrong in this case because this counter is linked to 'subflow' endpoints, and here it is a 'signal' endpoint that is being removed. Now, the counter is decremented, only if the ID is being used outside of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and if the ID is not 0 -- local_addr_used is not taking into account these ones. This marking of the ID as being available, and the decrement is done no matter if a subflow using this ID is currently available, because the subflow could have been closed before. • https://git.kernel.org/stable/c/06faa22710342bca5e9c249634199c650799fce6 https://git.kernel.org/stable/c/7fdc870d08960961408a44c569f20f50940e7d4f https://git.kernel.org/stable/c/43cf912b0b0fc7b4fd12cbc735d1f5afb8e1322d https://git.kernel.org/stable/c/9849cfc67383ceb167155186f8f8fe8a896b60b3 https://git.kernel.org/stable/c/322ea3778965da72862cca2a0c50253aacf65fe6 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-45009 – mptcp: pm: only decrement add_addr_accepted for MPJ req
https://notcve.org/view.php?id=CVE-2024-45009
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only decrement add_addr_accepted for MPJ req Adding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest. Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR. A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR. • https://git.kernel.org/stable/c/d0876b2284cf8b34dd214b2d0aa21071c345da59 https://git.kernel.org/stable/c/35b31f5549ede4070566b949781e83495906b43d https://git.kernel.org/stable/c/85b866e4c4e63a1d7afb58f1e24273caad03d0b7 https://git.kernel.org/stable/c/d20bf2c96d7ffd171299b32f562f70e5bf5dc608 https://git.kernel.org/stable/c/2060f1efab370b496c4903b840844ecaff324c3c https://git.kernel.org/stable/c/1c1f721375989579e46741f59523e39ec9b2a9bd •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45008 – Input: MT - limit max slots
https://notcve.org/view.php?id=CVE-2024-45008
In the Linux kernel, the following vulnerability has been resolved: Input: MT - limit max slots syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE). Since nobody knows possible max slots, this patch chose 1024. • https://git.kernel.org/stable/c/2829c80614890624456337e47320289112785f3e https://git.kernel.org/stable/c/87f610a1a7fbdb1f2e3d90b54c955bd3b8a0c322 https://git.kernel.org/stable/c/05dd9aabd04f9b5eb04dab9bb83d8c3e982d7549 https://git.kernel.org/stable/c/95f73d01f547dfc67fda3022c51e377a0454b505 https://git.kernel.org/stable/c/94736334b8a25e4fae8daa6934e54a31f099be43 https://git.kernel.org/stable/c/8f04edd554d191834e9e1349ef030318ea6b11ba https://git.kernel.org/stable/c/cd19f1799c32ba7b874474b1b968815ce5364f73 https://git.kernel.org/stable/c/99d3bf5f7377d42f8be60a6b9cb60fb0b •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-45007 – char: xillybus: Don't destroy workqueue from work item running on it
https://notcve.org/view.php?id=CVE-2024-45007
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Don't destroy workqueue from work item running on it Triggered by a kref decrement, destroy_workqueue() may be called from within a work item for destroying its own workqueue. This illegal situation is averted by adding a module-global workqueue for exclusive use of the offending work item. Other work items continue to be queued on per-device workqueues to ensure performance. • https://git.kernel.org/stable/c/409b495f8e3300d5fba08bc817fa8825dae48cc9 https://git.kernel.org/stable/c/5d3567caff2a1d678aa40cc74a54e1318941fad3 https://git.kernel.org/stable/c/a7ad105b12256ec7fb6d6d1a0e2e60f00b7da157 https://git.kernel.org/stable/c/aa1a19724fa2c31e97a9be48baedd4692b265157 https://git.kernel.org/stable/c/ccbde4b128ef9c73d14d0d7817d68ef795f6d131 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45006 – xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration
https://notcve.org/view.php?id=CVE-2024-45006
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference. Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint(). On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated. • https://git.kernel.org/stable/c/651aaf36a7d7b36a58980e70133f9437d4f6d312 https://git.kernel.org/stable/c/ef0a0e616b2789bb804a0ce5e161db03170a85b6 https://git.kernel.org/stable/c/a57b0ebabe6862dce0a2e0f13e17941ad72fc56b https://git.kernel.org/stable/c/0f0654318e25b2c185e245ba4a591e42fabb5e59 https://git.kernel.org/stable/c/365ef7c4277fdd781a695c3553fa157d622d805d https://git.kernel.org/stable/c/5ad898ae82412f8a689d59829804bff2999dd0ea https://git.kernel.org/stable/c/6b99de301d78e1f5249e57ef2c32e1dec3df2bb1 https://git.kernel.org/stable/c/8fb9d412ebe2f245f13481e4624b40e65 •