CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50165 – bpf: Preserve param->string when parsing mount options
https://notcve.org/view.php?id=CVE-2024-50165
In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve param->string when parsing mount options In bpf_parse_param(), keep the value of param->string intact so it can be freed later. Otherwise, the kmalloc area pointed to by param->string will be leaked as shown below: unreferenced object 0xffff888118c46d20 (size 8): comm "new_name", pid 12109, jiffies 4295580214 hex dump (first 8 bytes): 61 6e 79 00 38 c9 5c 7e any.8.\~ backtrace (crc e1b7f876): [<00000000c6848ac7>] kmemleak_alloc+0x4b/0x80 [<00000000de9f7d00>] __kmalloc_node_track_caller_noprof+0x36e/0x4a0 [<000000003e29b886>] memdup_user+0x32/0xa0 [<0000000007248326>] strndup_user+0x46/0x60 [<0000000035b3dd29>] __x64_sys_fsconfig+0x368/0x3d0 [<0000000018657927>] x64_sys_call+0xff/0x9f0 [<00000000c0cabc95>] do_syscall_64+0x3b/0xc0 [<000000002f331597>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: preservar param->string al analizar las opciones de montaje. En bpf_parse_param(), mantenga intacto el valor de param->string para que pueda liberarse más tarde. De lo contrario, el área kmalloc a la que apunta param->string se filtrará como se muestra a continuación: objeto sin referencia 0xffff888118c46d20 (tamaño 8): comm "new_name", pid 12109, jiffies 4295580214 volcado hexadecimal (primeros 8 bytes): 61 6e 79 00 38 c9 5c 7e any.8.\~ backtrace (crc e1b7f876): [<00000000c6848ac7>] kmemleak_alloc+0x4b/0x80 [<00000000de9f7d00>] __kmalloc_node_track_caller_noprof+0x36e/0x4a0 [<000000003e29b886>] memdup_user+0x32/0xa0 [<0000000007248326>] strndup_user+0x46/0x60 [<0000000035b3dd29>] __x64_sys_fsconfig+0x368/0x3d0 [<0000000018657927>] x64_sys_call+0xff/0x9f0 [<00000000c0cabc95>] do_syscall_64+0x3b/0xc0 [<000000002f331597>] entrada_SYSCALL_64_after_hwframe+0x4b/0x53 • https://git.kernel.org/stable/c/6c1752e0b6ca8c7021d6da3926738d8d88f601a9 https://git.kernel.org/stable/c/5d7a0a426540319327309035509cb768a2f5c2c4 https://git.kernel.org/stable/c/1f97c03f43fadc407de5b5cb01c07755053e1c22 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-50164 – bpf: Fix overloading of MEM_UNINIT's meaning
https://notcve.org/view.php?id=CVE-2024-50164
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overloading of MEM_UNINIT's meaning Lonial reported an issue in the BPF verifier where check_mem_size_reg() has the following code: if (!tnum_is_const(reg->var_off)) /* For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. */ meta = NULL; This means that writes are not checked when the register containing the size of the passed buffer has not a fixed size. Through this bug, a BPF program can write to a map which is marked as read-only, for example, .rodata global maps. The problem is that MEM_UNINIT's initial meaning that "the passed buffer to the BPF helper does not need to be initialized" which was added back in commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type") got overloaded over time with "the passed buffer is being written to". The problem however is that checks such as the above which were added later via 06c1c049721a ("bpf: allow helpers access to variable memory") set meta to NULL in order force the user to always initialize the passed buffer to the helper. Due to the current double meaning of MEM_UNINIT, this bypasses verifier write checks to the memory (not boundary checks though) and only assumes the latter memory is read instead. Fix this by reverting MEM_UNINIT back to its original meaning, and having MEM_WRITE as an annotation to BPF helpers in order to then trigger the BPF verifier checks for writing to memory. Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO} we can access fn->arg_type[arg - 1] since it must contain a preceding ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed altogether since we do check both BPF_READ and BPF_WRITE. • https://git.kernel.org/stable/c/7b3552d3f9f6897851fc453b5131a967167e43c2 https://git.kernel.org/stable/c/6099a6c8a749a5c8d5f8b4c4342022a92072a02b https://git.kernel.org/stable/c/bfe25df63048edd4ceaf78a2fc755d5e2befc978 https://git.kernel.org/stable/c/717c39718dbc4f7ebcbb7b625fb11851cd9007fe https://git.kernel.org/stable/c/5d0bba8232bf22ce13747cbfc8f696318ff01a50 https://git.kernel.org/stable/c/70674d11d14eeecad90be4b409a22b902112ba32 https://git.kernel.org/stable/c/a08d942ecbf46e23a192093f6983cb1d779f4fa8 https://git.kernel.org/stable/c/48068ccaea957469f1adf78dfd2c1c9a7 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50163 – bpf: Make sure internal and UAPI bpf_redirect flags don't overlap
https://notcve.org/view.php?id=CVE-2024-50163
In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Asegúrese de que los indicadores bpf_redirect internos y de UAPI no se superpongan El bpf_redirect_info se comparte entre las rutas de redireccionamiento de SKB y XDP, y las dos rutas usan los mismos valores de indicador numérico en el campo ri->flags (específicamente, BPF_F_BROADCAST == BPF_F_NEXTHOP). • https://git.kernel.org/stable/c/e624d4ed4aa8cc3c69d1359b0aaea539203ed266 https://git.kernel.org/stable/c/4e1e428533845d48828bd3875c0e92e8565b9962 https://git.kernel.org/stable/c/314dbee9fe4f5cee36435465de52c988d7caa466 https://git.kernel.org/stable/c/0fca5ed4be8e8bfbfb9bd97845af596bab7192d3 https://git.kernel.org/stable/c/cec288e05ceac9a0d3a3a1fd279534b11844c826 https://git.kernel.org/stable/c/09d88791c7cd888d5195c84733caf9183dcfbd16 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50162 – bpf: devmap: provide rxq after redirect
https://notcve.org/view.php?id=CVE-2024-50162
In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set. This is particularly bad since accessing ingress_ifindex, e.g. SEC("xdp") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC("xdp/devmap") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS; } depends on access to rxq, so a NULL pointer gets dereferenced: <1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 574.475188] #PF: supervisor read access in kernel mode <1>[ 574.475194] #PF: error_code(0x0000) - not-present page <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 <4>[ 574.475231] Workqueue: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Call Trace: <4>[ 574.475313] <IRQ> <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490 <4>[ 574.475346] ? • https://git.kernel.org/stable/c/cb261b594b4108668e00f565184c7c221efe0359 https://git.kernel.org/stable/c/fe068afb868660fe683a8391c6c17ecbe2254922 https://git.kernel.org/stable/c/a778fbe087c19f4ece5f5fc14173328f070c3803 https://git.kernel.org/stable/c/49454f09936a9a96edfb047156889879cb4001eb https://git.kernel.org/stable/c/9167d1c274a336e4763eeb3f3f9cb763c55df5aa https://git.kernel.org/stable/c/ca9984c5f0ab3690d98b13937b2485a978c8dd73 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50161 – bpf: Check the remaining info_cnt before repeating btf fields
https://notcve.org/view.php?id=CVE-2024-50161
In the Linux kernel, the following vulnerability has been resolved: bpf: Check the remaining info_cnt before repeating btf fields When trying to repeat the btf fields for array of nested struct, it doesn't check the remaining info_cnt. The following splat will be reported when the value of ret * nelems is greater than BTF_FIELDS_MAX: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ../kernel/bpf/btf.c:3951:49 index 11 is out of range for type 'btf_field_info [11]' CPU: 6 UID: 0 PID: 411 Comm: test_progs ...... 6.11.0-rc4+ #1 Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ... Call Trace: <TASK> dump_stack_lvl+0x57/0x70 dump_stack+0x10/0x20 ubsan_epilogue+0x9/0x40 __ubsan_handle_out_of_bounds+0x6f/0x80 ? kallsyms_lookup_name+0x48/0xb0 btf_parse_fields+0x992/0xce0 map_create+0x591/0x770 __sys_bpf+0x229/0x2410 __x64_sys_bpf+0x1f/0x30 x64_sys_call+0x199/0x9f0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fea56f2cc5d ...... </TASK> ---[ end trace ]--- Fix it by checking the remaining info_cnt in btf_repeat_fields() before repeating the btf fields. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Verificar el info_cnt restante antes de repetir los campos btf Al intentar repetir los campos btf para una matriz de estructuras anidadas, no verifica el info_cnt restante. • https://git.kernel.org/stable/c/64e8ee814819f21beeeda00d4119221443d77992 https://git.kernel.org/stable/c/6f957d972feee9b385ea3ae6530310a84e55ba71 https://git.kernel.org/stable/c/797d73ee232dd1833dec4824bc53a22032e97c1c •