CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56707 – octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c
https://notcve.org/view.php?id=CVE-2024-56707
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c Add error pointer checks after calling otx2_mbox_get_rsp(). • https://git.kernel.org/stable/c/79d2be385e9eabe4403eb85bcc7d3efc6b936a76 https://git.kernel.org/stable/c/1611b1ea7cf8d07dff091a45389b10401bb6d5b3 https://git.kernel.org/stable/c/3ccbc7a518868eff1d5a198b9e454e182b651e00 https://git.kernel.org/stable/c/20e06a5137a1174214bae3a29ce623e69455ee0f https://git.kernel.org/stable/c/fc595472fbad96533ccbb7b9ebb82b743ec26829 https://git.kernel.org/stable/c/f5b942e6c54b13246ee49d42dcfb71b7f29e3c64 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56705 – media: atomisp: Add check for rgby_data memory allocation failure
https://notcve.org/view.php?id=CVE-2024-56705
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: Add check for rgby_data memory allocation failure In ia_css_3a_statistics_allocate(), there is no check on the allocation result of the rgby_data memory. If rgby_data is not successfully allocated, it may trigger the assert(host_stats->rgby_data) assertion in ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. • https://git.kernel.org/stable/c/a49d25364dfb9f8a64037488a39ab1f56c5fa419 https://git.kernel.org/stable/c/0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a https://git.kernel.org/stable/c/4676e50444046b498555b849e6080a5c78cdda9b https://git.kernel.org/stable/c/02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 https://git.kernel.org/stable/c/8066badaf7463194473fb4be19dbe50b11969aa0 https://git.kernel.org/stable/c/74aa783682c4d78c69d87898e40c78df1fec204e https://git.kernel.org/stable/c/0c25ab93f2878cab07d37ca5afd302283201e5af https://git.kernel.org/stable/c/ed61c59139509f76d3592683c90dc3fdc •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56704 – 9p/xen: fix release of IRQ
https://notcve.org/view.php?id=CVE-2024-56704
In the Linux kernel, the following vulnerability has been resolved: 9p/xen: fix release of IRQ Kernel logs indicate an IRQ was double-freed. Pass correct device ID during IRQ release. [Dominique: remove confusing variable reset to 0] • https://git.kernel.org/stable/c/71ebd71921e451f0f942ddfe85d01e31ddc6eb88 https://git.kernel.org/stable/c/692eb06703afc3e24d889d77e94a0e20229f6a4a https://git.kernel.org/stable/c/d74b4b297097bd361b8a9abfde9b521ff464ea9c https://git.kernel.org/stable/c/7f5a2ed5c1810661e6b03f5a4ebf17682cdea850 https://git.kernel.org/stable/c/4950408793b118cb8075bcee1f033b543fb719fa https://git.kernel.org/stable/c/b9e26059664bd9ebc64a0e8f5216266fc9f84265 https://git.kernel.org/stable/c/2bb3ee1bf237557daea1d58007d2e1d4a6502ccf https://git.kernel.org/stable/c/d888f5f5d76b2722c267e6bdf51d445d6 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56703 – ipv6: Fix soft lockups in fib6_select_path under high next hop churn
https://notcve.org/view.php?id=CVE-2024-56703
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix soft lockups in fib6_select_path under high next hop churn Soft lockups have been observed on a cluster of Linux-based edge routers located in a highly dynamic environment. Using the `bird` service, these routers continuously update BGP-advertised routes due to frequently changing nexthop destinations, while also managing significant IPv6 traffic. The lockups occur during the traversal of the multipath circular linked-list in the `fib6_select_path` function, particularly while iterating through the siblings in the list. The issue typically arises when the nodes of the linked list are unexpectedly deleted concurrently on a different core—indicated by their 'next' and 'previous' elements pointing back to the node itself and their reference count dropping to zero. This results in an infinite loop, leading to a soft lockup that triggers a system panic via the watchdog timer. Apply RCU primitives in the problematic code sections to resolve the issue. • https://git.kernel.org/stable/c/66f5d6ce53e665477d2a33e8f539d4fa4ca81c83 https://git.kernel.org/stable/c/11edcd026012ac18acee0f1514db3ed1b160fc6f https://git.kernel.org/stable/c/34a949e7a0869dfa31a40416d2a56973fae1807b https://git.kernel.org/stable/c/d9ccb18f83ea2bb654289b6ecf014fd267cc988b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56702 – bpf: Mark raw_tp arguments with PTR_MAYBE_NULL
https://notcve.org/view.php?id=CVE-2024-56702
In the Linux kernel, the following vulnerability has been resolved: bpf: Mark raw_tp arguments with PTR_MAYBE_NULL Arguments to a raw tracepoint are tagged as trusted, which carries the semantics that the pointer will be non-NULL. However, in certain cases, a raw tracepoint argument may end up being NULL. More context about this issue is available in [0]. Thus, there is a discrepancy between the reality, that raw_tp arguments can actually be NULL, and the verifier's knowledge, that they are never NULL, causing explicit NULL checks to be deleted, and accesses to such pointers potentially crashing the kernel. To fix this, mark raw_tp arguments as PTR_MAYBE_NULL, and then special case the dereference and pointer arithmetic to permit it, and allow passing them into helpers/kfuncs; these exceptions are made for raw_tp programs only. Ensure that we don't do this when ref_obj_id > 0, as in that case this is an acquired object and doesn't need such adjustment. The reason we do mask_raw_tp_trusted_reg logic is because other will recheck in places whether the register is a trusted_reg, and then consider our register as untrusted when detecting the presence of the PTR_MAYBE_NULL flag. To allow safe dereference, we enable PROBE_MEM marking when we see loads into trusted pointers with PTR_MAYBE_NULL. While trusted raw_tp arguments can also be passed into helpers or kfuncs where such broken assumption may cause issues, a future patch set will tackle their case separately, as PTR_TO_BTF_ID (without PTR_TRUSTED) can already be passed into helpers and causes similar problems. Thus, they are left alone for now. It is possible that these checks also permit passing non-raw_tp args that are trusted PTR_TO_BTF_ID with null marking. • https://git.kernel.org/stable/c/3f00c52393445ed49aadc1a567aa502c6333b1a1 https://git.kernel.org/stable/c/c9b91d2d54175f781ad2c361cb2ac2c0e29b14b6 https://git.kernel.org/stable/c/3634d4a310820567fc634bf8f1ee2b91378773e8 https://git.kernel.org/stable/c/cb4158ce8ec8a5bb528cc1693356a5eb8058094d •