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: 5EXPL: 0CVE-2024-50160 – ALSA: hda/cs8409: Fix possible NULL dereference
https://notcve.org/view.php?id=CVE-2024-50160
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda/cs8409: Se corrige una posible desreferencia de NULL. Si snd_hda_gen_add_kctl no puede asignar memoria y devuelve NULL, se producirá una desreferencia de puntero NULL en la siguiente línea. Dado que la función dolphin_fixups es una función hda_fixup que no debería devolver ningún error, se debe agregar una comprobación simple antes de la desreferencia e ignorar el error. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/20e507724113300794f16884e7e7507d9b4dec68 https://git.kernel.org/stable/c/4e19aca8db696b6ba4dd8c73657405e15c695f14 https://git.kernel.org/stable/c/21dc97d5086fdabbe278786bb0a03cbf2e26c793 https://git.kernel.org/stable/c/8971fd61210d75fd2af225621cd2fcc87eb1847c https://git.kernel.org/stable/c/a5dd71a8b849626f42d08a5e73d382f2016fc7bc https://git.kernel.org/stable/c/c9bd4a82b4ed32c6d1c90500a52063e6e341517f •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50156 – drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()
https://notcve.org/view.php?id=CVE-2024-50156
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since "dump_addr" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print "Registers not stored" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`. Patchwork: https://patchwork.freedesktop.org/patch/619657/ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm: Evitar la desreferenciación NULL en msm_disp_state_print_regs() Si la asignación en msm_disp_state_dump_regs() falla, entonces `block->state` puede ser NULL. La función msm_disp_state_print_regs() _sí_ tiene código para intentar manejarlo con: if (*reg) dump_addr = *reg; ...pero como "dump_addr" se inicializa a NULL, lo anterior es en realidad un noop. • https://git.kernel.org/stable/c/98659487b845c05b6bed85d881713545db674c7c https://git.kernel.org/stable/c/42cf045086feae77b212f0f66e742b91a5b566b7 https://git.kernel.org/stable/c/e8e9f2a12a6214080c8ea83220a596f6e1dedc6c https://git.kernel.org/stable/c/f7ad916273483748582d97cfa31054ccb19224f3 https://git.kernel.org/stable/c/563aa81fd66a4e7e6e551a0e02bcc23957cafe2f https://git.kernel.org/stable/c/293f53263266bc4340d777268ab4328a97f041fa •