CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50168 – net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()
https://notcve.org/view.php?id=CVE-2024-50168
In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sun3_82586: corrige una posible pérdida de memoria en sun3_82586_send_packet(). sun3_82586_send_packet() devuelve NETDEV_TX_OK sin liberar skb en caso de que skb->len sea demasiado largo, agrega dev_kfree_skb() para solucionarlo. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/137010d26dc5cd47cd62fef77cbe952d31951b7a https://git.kernel.org/stable/c/8d5b20fbc548650019afa96822b6a33ea4ec8aa5 https://git.kernel.org/stable/c/db755e55349045375c5c7036e8650afb3ff419d8 https://git.kernel.org/stable/c/9c6ce55e6f0bd1541f112833006b4052614c7d94 https://git.kernel.org/stable/c/1a17a4ac2d57102497fac53b53c666dba6a0c20d https://git.kernel.org/stable/c/6dc937a3086e344f965ca5c459f8f3eb6b68d890 https://git.kernel.org/stable/c/84f2bac74000dbb7a177d9b98a17031ec •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50167 – be2net: fix potential memory leak in be_xmit()
https://notcve.org/view.php?id=CVE-2024-50167
In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: be2net: corrige una posible pérdida de memoria en be_xmit(). Be_xmit() devuelve NETDEV_TX_OK sin liberar skb en caso de que be_xmit_enqueue() falle, agregue dev_kfree_skb_any() para solucionarlo. • https://git.kernel.org/stable/c/760c295e0e8d982917d004c9095cff61c0cbd803 https://git.kernel.org/stable/c/941026023c256939943a47d1c66671526befbb26 https://git.kernel.org/stable/c/6b7ce8ee01c33c380aaa5077ff25215492e7eb0e https://git.kernel.org/stable/c/77bc881d370e850b7f3cd2b5eae67d596b40efbc https://git.kernel.org/stable/c/919ab6e2370289a2748780f44a43333cd3878aa7 https://git.kernel.org/stable/c/4c5f170ef4f85731a4d43ad9a6ac51106c0946be https://git.kernel.org/stable/c/641c1beed52bf3c6deb0193fe4d38ec9ff75d2ae https://git.kernel.org/stable/c/e86a79b804e26e3b7f1e415b22a085c0b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50166 – fsl/fman: Fix refcount handling of fman-related devices
https://notcve.org/view.php?id=CVE-2024-50166
In the Linux kernel, the following vulnerability has been resolved: fsl/fman: Fix refcount handling of fman-related devices In mac_probe() there are multiple calls to of_find_device_by_node(), fman_bind() and fman_port_bind() which takes references to of_dev->dev. Not all references taken by these calls are released later on error path in mac_probe() and in mac_remove() which lead to reference leaks. Add references release. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fsl/fman: se ha corregido el manejo de refcount de dispositivos relacionados con fman En mac_probe() hay múltiples llamadas a of_find_device_by_node(), fman_bind() y fman_port_bind() que toman referencias a of_dev->dev. No todas las referencias tomadas por estas llamadas se liberan más tarde en la ruta de error en mac_probe() y en mac_remove(), lo que provoca fugas de referencias. Agregar referencias release. • https://git.kernel.org/stable/c/3933961682a30ae7d405cda344c040a129fea422 https://git.kernel.org/stable/c/5ed4334fc9512f934fe2ae9c4cf7f8142e451b8b https://git.kernel.org/stable/c/3c2a3619d565fe16bf59b0a047bab103a2ee4490 https://git.kernel.org/stable/c/1dec67e0d9fbb087c2ab17bf1bd17208231c3bb1 •
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 •