CVE-2024-27399 – Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
https://notcve.org/view.php?id=CVE-2024-27399
13 May 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout There is a race condition between l2cap_chan_timeout() and l2cap_chan_del(). When we use l2cap_chan_del() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutex_lock() of l2cap_chan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below: [ 472.074580] ============... • https://git.kernel.org/stable/c/3df91ea20e744344100b10ae69a17211fcf5b207 •
CVE-2024-27398 – Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
https://notcve.org/view.php?id=CVE-2024-27398
13 May 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout When the sco connection is established and then, the sco socket is releasing, timeout_work will be scheduled to judge whether the sco disconnection is timeout. The sock will be deallocated later, but it is dereferenced again in sco_sock_timeout. As a result, the use-after-free bugs will happen. The root cause is shown below: Cleanup Thread | Worker Thread sco_sock_release | sco_s... • https://git.kernel.org/stable/c/48669c81a65628ef234cbdd91b9395952c7c27fe •
CVE-2023-52655 – usb: aqc111: check packet for fixup for true limit
https://notcve.org/view.php?id=CVE-2023-52655
13 May 2024 — In the Linux kernel, the following vulnerability has been resolved: usb: aqc111: check packet for fixup for true limit If a device sends a packet that is inbetween 0 and sizeof(u64) the value passed to skb_trim() as length will wrap around ending up as some very large value. The driver will then proceed to parse the header located at that position, which will either oops or process some random value. The fix is to check against sizeof(u64) rather than 0, which the driver currently does. The issue exists sin... • https://git.kernel.org/stable/c/84f2e5b3e70f08fce3cb1ff73414631c5e490204 •
CVE-2024-27397 – netfilter: nf_tables: use timestamp to check for set element timeout
https://notcve.org/view.php?id=CVE-2024-27397
09 May 2024 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: use timestamp to check for set element timeout Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area. Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished. .lookup and .update, which are used from packet path, still use the current time to check if the element ha... • https://git.kernel.org/stable/c/c3e1b005ed1cc068fc9d454a6e745830d55d251d •
CVE-2024-27396 – net: gtp: Fix Use-After-Free in gtp_dellink
https://notcve.org/view.php?id=CVE-2024-27396
09 May 2024 — In the Linux kernel, the following vulnerability has been resolved: net: gtp: Fix Use-After-Free in gtp_dellink Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of gtp_dellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gtp: corrige Use-After-Fre... • https://git.kernel.org/stable/c/043a283d24f40fea4c8a8d06b0e2694c8e372200 •
CVE-2024-27395 – net: openvswitch: Fix Use-After-Free in ovs_ct_exit
https://notcve.org/view.php?id=CVE-2024-27395
09 May 2024 — In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix Use-After-Free in ovs_ct_exit Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal of ovs_ct_limit_exit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch... • https://git.kernel.org/stable/c/11efd5cb04a184eea4f57b68ea63dddd463158d1 •
CVE-2024-27393 – xen-netfront: Add missing skb_mark_for_recycle
https://notcve.org/view.php?id=CVE-2024-27393
09 May 2024 — In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: pag... • https://git.kernel.org/stable/c/6c5aa6fc4defc2a0977a2c59e4710d50fa1e834c •
CVE-2023-52654 – io_uring/af_unix: disable sending io_uring over sockets
https://notcve.org/view.php?id=CVE-2023-52654
09 May 2024 — In the Linux kernel, the following vulnerability has been resolved: io_uring/af_unix: disable sending io_uring over sockets File reference cycles have caused lots of problems for io_uring in the past, and it still doesn't work exactly right and races with unix_stream_read_generic(). The safest fix would be to completely disallow sending io_uring files via sockets via SCM_RIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary. En e... • https://github.com/FoxyProxys/CVE-2023-52654 •
CVE-2022-48705 – wifi: mt76: mt7921e: fix crash in chip reset fail
https://notcve.org/view.php?id=CVE-2022-48705
03 May 2024 — In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921e: fix crash in chip reset fail In case of drv own fail in reset, we may need to run mac_reset several times. The sequence would trigger system crash as the log below. Because we do not re-enable/schedule "tx_napi" before disable it again, the process would keep waiting for state change in napi_diable(). To avoid the problem and keep status synchronize for each run, goto final resource handling if drv own failed. [ 5857.35... • https://git.kernel.org/stable/c/0efaf31dec572d3aac4316c6d952e06d1c33adc4 •
CVE-2022-48704 – drm/radeon: add a force flush to delay work when radeon
https://notcve.org/view.php?id=CVE-2022-48704
03 May 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/radeon: add a force flush to delay work when radeon Although radeon card fence and wait for gpu to finish processing current batch rings, there is still a corner case that radeon lockup work queue may not be fully flushed, and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to put device in D3hot state. Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State. > Configuration and Message requests are the only TLPs acce... • https://git.kernel.org/stable/c/b878da58df2c40b08914d3960e2224040fd1fbfe •