CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44994 – iommu: Restore lost return in iommu_report_device_fault()
https://notcve.org/view.php?id=CVE-2024-44994
In the Linux kernel, the following vulnerability has been resolved: iommu: Restore lost return in iommu_report_device_fault() When iommu_report_device_fault gets called with a partial fault it is supposed to collect the fault into the group and then return. Instead the return was accidently deleted which results in trying to process the fault and an eventual crash. Deleting the return was a typo, put it back. • https://git.kernel.org/stable/c/3dfa64aecbafc288216b2790438d395add192c30 https://git.kernel.org/stable/c/cc6bc2ab1663ec9353636416af22452b078510e9 https://git.kernel.org/stable/c/fca5b78511e98bdff2cdd55c172b23200a7b3404 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44993 – drm/v3d: Fix out-of-bounds read in `v3d_csd_job_run()`
https://notcve.org/view.php?id=CVE-2024-44993
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix out-of-bounds read in `v3d_csd_job_run()` When enabling UBSAN on Raspberry Pi 5, we get the following warning: [ 387.894977] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/v3d/v3d_sched.c:320:3 [ 387.903868] index 7 is out of range for type '__u32 [7]' [ 387.909692] CPU: 0 PID: 1207 Comm: kworker/u16:2 Tainted: G WC 6.10.3-v8-16k-numa #151 [ 387.919166] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 387.925961] Workqueue: v3d_csd drm_sched_run_job_work [gpu_sched] [ 387.932525] Call trace: [ 387.935296] dump_backtrace+0x170/0x1b8 [ 387.939403] show_stack+0x20/0x38 [ 387.942907] dump_stack_lvl+0x90/0xd0 [ 387.946785] dump_stack+0x18/0x28 [ 387.950301] __ubsan_handle_out_of_bounds+0x98/0xd0 [ 387.955383] v3d_csd_job_run+0x3a8/0x438 [v3d] [ 387.960707] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ 387.966862] process_one_work+0x62c/0xb48 [ 387.971296] worker_thread+0x468/0x5b0 [ 387.975317] kthread+0x1c4/0x1e0 [ 387.978818] ret_from_fork+0x10/0x20 [ 387.983014] ---[ end trace ]--- This happens because the UAPI provides only seven configuration registers and we are reading the eighth position of this u32 array. Therefore, fix the out-of-bounds read in `v3d_csd_job_run()` by accessing only seven positions on the '__u32 [7]' array. The eighth register exists indeed on V3D 7.1, but it isn't currently used. That being so, let's guarantee that it remains unused and add a note that it could be set in a future patch. • https://git.kernel.org/stable/c/0ad5bc1ce4634ce9b5eaf017b01399ec5e49a03d https://git.kernel.org/stable/c/d656b82c4b30cf12715e6cd129d3df808fde24a7 https://git.kernel.org/stable/c/497d370a644d95a9f04271aa92cb96d32e84c770 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-44991 – tcp: prevent concurrent execution of tcp_sk_exit_batch
https://notcve.org/view.php?id=CVE-2024-44991
In the Linux kernel, the following vulnerability has been resolved: tcp: prevent concurrent execution of tcp_sk_exit_batch Its possible that two threads call tcp_sk_exit_batch() concurrently, once from the cleanup_net workqueue, once from a task that failed to clone a new netns. In the latter case, error unwinding calls the exit handlers in reverse order for the 'failed' netns. tcp_sk_exit_batch() calls tcp_twsk_purge(). Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"), this function picks up twsk in any dying netns, not just the one passed in via exit_batch list. This means that the error unwind of setup_net() can "steal" and destroy timewait sockets belonging to the exiting netns. This allows the netns exit worker to proceed to call WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount)); without the expected 1 -> 0 transition, which then splats. At same time, error unwind path that is also running inet_twsk_purge() will splat as well: WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [inline] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 ... because refcount_dec() of tw_refcount unexpectedly dropped to 0. This doesn't seem like an actual bug (no tw sockets got lost and I don't see a use-after-free) but as erroneous trigger of debug check. Add a mutex to force strict ordering: the task that calls tcp_twsk_purge() blocks other task from doing final _dec_and_test before mutex-owner has removed all tw sockets of dying netns. • https://git.kernel.org/stable/c/e9bd0cca09d13ac2f08d25e195203e42d4ad1ce8 https://git.kernel.org/stable/c/e3d9de3742f4d5c47ae35f888d3023a5b54fcd2f https://git.kernel.org/stable/c/99580ae890ec8bd98b21a2a9c6668f8f1555b62e https://git.kernel.org/stable/c/f6fd2dbf584a4047ba88d1369ff91c9851261ec1 https://git.kernel.org/stable/c/565d121b69980637f040eb4d84289869cdaabedf •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-44990 – bonding: fix null pointer deref in bond_ipsec_offload_ok
https://notcve.org/view.php?id=CVE-2024-44990
In the Linux kernel, the following vulnerability has been resolved: bonding: fix null pointer deref in bond_ipsec_offload_ok We must check if there is an active slave before dereferencing the pointer. • https://git.kernel.org/stable/c/18cb261afd7bf50134e5ccacc5ec91ea16efadd4 https://git.kernel.org/stable/c/81216b9352be43f8958092d379f6dec85443c309 https://git.kernel.org/stable/c/2f5bdd68c1ce64bda6bef4d361a3de23b04ccd59 https://git.kernel.org/stable/c/32a0173600c63aadaf2103bf02f074982e8602ab https://git.kernel.org/stable/c/0707260a18312bbcd2a5668584e3692d0a29e3f6 https://git.kernel.org/stable/c/b70b0ddfed31fc92c8dc722d0afafc8e14cb550c https://git.kernel.org/stable/c/95c90e4ad89d493a7a14fa200082e466e2548f9d https://access.redhat.com/security/cve/CVE-2024-44990 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-44989 – bonding: fix xfrm real_dev null pointer dereference
https://notcve.org/view.php?id=CVE-2024-44989
In the Linux kernel, the following vulnerability has been resolved: bonding: fix xfrm real_dev null pointer dereference We shouldn't set real_dev to NULL because packets can be in transit and xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume real_dev is set. Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: error_code(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: <TASK> kernel: ? __die+0x1f/0x60 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? • https://git.kernel.org/stable/c/18cb261afd7bf50134e5ccacc5ec91ea16efadd4 https://git.kernel.org/stable/c/21816b696c172c19d53a30d45ee005cce246ed21 https://git.kernel.org/stable/c/2f72c6a66bcd7e0187ec085237fee5db27145294 https://git.kernel.org/stable/c/7fa9243391ad2afe798ef4ea2e2851947b95754f https://git.kernel.org/stable/c/4582d4ff413a07d4ed8a4823c652dc5207760548 https://git.kernel.org/stable/c/89fc1dca79db5c3e7a2d589ecbf8a3661c65f436 https://git.kernel.org/stable/c/f8cde9805981c50d0c029063dc7d82821806fc44 https://access.redhat.com/security/cve/CVE-2024-44989 • CWE-476: NULL Pointer Dereference •