CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53093 – nvme-multipath: defer partition scanning
https://notcve.org/view.php?id=CVE-2024-53093
In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work. • https://git.kernel.org/stable/c/60de2e03f984cfbcdc12fa552f95087c35a05a98 https://git.kernel.org/stable/c/4a57f42e5ed42cb8f1beb262c4f6d3e698939e4e https://git.kernel.org/stable/c/a91b7eddf45afeeb9c5ece11dddff5de0921b00f https://git.kernel.org/stable/c/1f021341eef41e77a633186e9be5223de2ce5d48 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53091 – bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx
https://notcve.org/view.php?id=CVE-2024-53091
In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? • https://git.kernel.org/stable/c/94531cfcbe79c3598acf96806627b2137ca32eb9 https://git.kernel.org/stable/c/a078a480ff3f43d74d8a024ae10c3c7daf6db149 https://git.kernel.org/stable/c/6781cfa93a6a1b7f5be6819a5a2dd8f30f47ca26 https://git.kernel.org/stable/c/44d0469f79bd3d0b3433732877358df7dc6b17b1 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53090 – afs: Fix lock recursion
https://notcve.org/view.php?id=CVE-2024-53090
In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <TASK> dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? • https://git.kernel.org/stable/c/d7cbf81df996b1eae2dee8deb6df08e2eba78661 https://git.kernel.org/stable/c/610a79ffea02102899a1373fe226d949944a7ed6 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53088 – i40e: fix race condition by adding filter's intermediate sync state
https://notcve.org/view.php?id=CVE-2024-53088
In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. • https://git.kernel.org/stable/c/278e7d0b9d6864a9749b9473a273892aa1528621 https://git.kernel.org/stable/c/262dc6ea5f1eb18c4d08ad83d51222d0dd0dd42a https://git.kernel.org/stable/c/7ad3fb3bfd43feb4e15c81dffd23ac4e55742791 https://git.kernel.org/stable/c/bf5f837d9fd27d32fb76df0a108babcaf4446ff1 https://git.kernel.org/stable/c/6e046f4937474bc1b9fa980c1ad8f3253fc638f6 https://git.kernel.org/stable/c/f30490e9695ef7da3d0899c6a0293cc7cd373567 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53084 – drm/imagination: Break an object reference loop
https://notcve.org/view.php?id=CVE-2024-53084
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler "finished" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context. • https://git.kernel.org/stable/c/cb86db12b290ed07d05df00d99fa150bb123e80e https://git.kernel.org/stable/c/b04ce1e718bd55302b52d05d6873e233cb3ec7a1 •