CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42066 – drm/xe: Fix potential integer overflow in page size calculation
https://notcve.org/view.php?id=CVE-2024-42066
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix potential integer overflow in page size calculation Explicitly cast tbo->page_alignment to u64 before bit-shifting to prevent overflow when assigning to min_page_size. • https://git.kernel.org/stable/c/79d54ddf0e292b810887994bb04709c5ac0e1531 https://git.kernel.org/stable/c/4f4fcafde343a54465f85a2909fc684918507a4b •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42065 – drm/xe: Add a NULL check in xe_ttm_stolen_mgr_init
https://notcve.org/view.php?id=CVE-2024-42065
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Add a NULL check in xe_ttm_stolen_mgr_init Add an explicit check to ensure that the mgr is not NULL. • https://git.kernel.org/stable/c/cc796a77985d6af75c9362cb2e73dce4ae3f97cd https://git.kernel.org/stable/c/a6eff8f9c7e844cb24ccb188ca24abcd59734e74 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42064 – drm/amd/display: Skip pipe if the pipe idx not set properly
https://notcve.org/view.php?id=CVE-2024-42064
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip pipe if the pipe idx not set properly [why] Driver crashes when pipe idx not set properly [how] Add code to skip the pipe that idx not set properly • https://git.kernel.org/stable/c/27df59c6071470efce7182ee92fbb16afba551e0 https://git.kernel.org/stable/c/af114efe8d24b5711cfbedf7180f2ac1a296c24b •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42063 – bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode
https://notcve.org/view.php?id=CVE-2024-42063
In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode syzbot reported uninit memory usages during map_{lookup,delete}_elem. ========== BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 ____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline] bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237 ========== The reproducer should be in the interpreter mode. The C reproducer is trying to run the following bpf prog: 0: (18) r0 = 0x0 2: (18) r1 = map[id:49] 4: (b7) r8 = 16777216 5: (7b) *(u64 *)(r10 -8) = r8 6: (bf) r2 = r10 7: (07) r2 += -229 ^^^^^^^^^^ 8: (b7) r3 = 8 9: (b7) r4 = 0 10: (85) call dev_map_lookup_elem#1543472 11: (95) exit It is due to the "void *key" (r2) passed to the helper. bpf allows uninit stack memory access for bpf prog with the right privileges. This patch uses kmsan_unpoison_memory() to mark the stack as initialized. This should address different syzbot reports on the uninit "void *key" argument during map_{lookup,delete}_elem. • https://git.kernel.org/stable/c/b30f3197a6cd080052d5d4973f9a6b479fd9fff5 https://git.kernel.org/stable/c/d812ae6e02bd6e6a9cd1fdb09519c2f33e875faf https://git.kernel.org/stable/c/3189983c26108cf0990e5c46856dc9feb9470d12 https://git.kernel.org/stable/c/e8742081db7d01f980c6161ae1e8a1dbc1e30979 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52887 – net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
https://notcve.org/view.php?id=CVE-2023-52887
In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done • https://git.kernel.org/stable/c/9d71dd0c70099914fcd063135da3c580865e924c https://git.kernel.org/stable/c/ed581989d7ea9df6f8646beba2341e32cd49a1f9 https://git.kernel.org/stable/c/f6c839e717901dbd6b1c1ca807b6210222eb70f6 https://git.kernel.org/stable/c/1762ca80c2b72dd1b5821c5e347713ae696276ea https://git.kernel.org/stable/c/26b18dd30e63d4fd777be429148e8e4ed66f60b2 https://git.kernel.org/stable/c/177e33b655d35d72866b50aec84307119dc5f3d4 https://git.kernel.org/stable/c/0bc0a7416ea73f79f915c9a05ac0858dff65cfed https://git.kernel.org/stable/c/d3e2904f71ea0fe7eaff1d68a2b0363c8 •