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: 8EXPL: 0CVE-2024-41095 – drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
https://notcve.org/view.php?id=CVE-2024-41095
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. • https://git.kernel.org/stable/c/9289cd3450d1da3e271ef4b054d4d2932c41243e https://git.kernel.org/stable/c/dbd75f32252508ed6c46c3288a282c301a57ceeb https://git.kernel.org/stable/c/259549b2ccf795b7f91f7b5aba47286addcfa389 https://git.kernel.org/stable/c/0d17604f2e44b3df21e218fe8fb3b836d41bac49 https://git.kernel.org/stable/c/f95ed0f54b3d3faecae1140ddab854f904a6e7c8 https://git.kernel.org/stable/c/cb751e48bbcffd292090f7882b23b215111b3d72 https://git.kernel.org/stable/c/bdda5072494f2a7215d94fc4124ad1949a218714 https://git.kernel.org/stable/c/66edf3fb331b6c55439b10f9862987b09 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-41093 – drm/amdgpu: avoid using null object of framebuffer
https://notcve.org/view.php?id=CVE-2024-41093
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. • https://git.kernel.org/stable/c/7f35e01cb0ea4d295f5c067bb5c67dfcddaf05bc https://git.kernel.org/stable/c/6ce0544cabaa608018d5922ab404dc656a9d8447 https://git.kernel.org/stable/c/330c8c1453848c04d335bad81371a66710210800 https://git.kernel.org/stable/c/dd9ec0ea4cdde0fc48116e63969fc83e81d7ef46 https://git.kernel.org/stable/c/bcfa48ff785bd121316592b131ff6531e3e696bb •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41089 – drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
https://notcve.org/view.php?id=CVE-2024-41089
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. • https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51 https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50 https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0 https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637 https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59 https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41082 – nvme-fabrics: use reserved tag for reg read/write command
https://notcve.org/view.php?id=CVE-2024-41082
In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: use reserved tag for reg read/write command In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. • https://git.kernel.org/stable/c/165da9c67a26f08c9b956c15d701da7690f45bcb https://git.kernel.org/stable/c/7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa •