CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26804 – net: ip_tunnel: prevent perpetual headroom growth
https://notcve.org/view.php?id=CVE-2024-26804
In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ip_tunnel: evita el crecimiento perpetuo del espacio libre syzkaller activado después de kasan splat: ERROR: KASAN: use-after-free en __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Lectura del tamaño 1 en la dirección ffff88812fb4000e mediante la tarea syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_key incluir/linux /skbuff.h:1514 [en línea] ___skb_get_hash net/core/flow_dissector.c:1791 [en línea] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [en línea] ip_tunnel_xmit +0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice .h:3134 [en línea] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c :323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit incluir /linux /netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 . .. • https://git.kernel.org/stable/c/243aad830e8a4cdda261626fbaeddde16b08d04a https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383 https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282 https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96 https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9 https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26803 – net: veth: clear GRO when clearing XDP even when down
https://notcve.org/view.php?id=CVE-2024-26803
In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances. We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable(). If it never was we'll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: veth: borra GRO al borrar XDP incluso cuando está desactivado veth configura NETIF_F_GRO automáticamente cuando XDP está habilitado, porque ambas funciones utilizan la misma maquinaria NAPI. • https://git.kernel.org/stable/c/d3256efd8e8b234a6251e4d4580bd2c3c31fdc4c https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325 https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664 https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941 https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26802 – stmmac: Clear variable when destroying workqueue
https://notcve.org/view.php?id=CVE-2024-26802
In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped, it will cause kernel/module panic. To secure against this possible crash, set workqueue variable to NULL when destroying workqueue. Log/backtrace from crash goes as follows: [88.031977]------------[ cut here ]------------ [88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out [88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 <Skipping backtrace for watchdog timeout> [88.032251]---[ end trace e70de432e4d5c2c0 ]--- [88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter. [88.036359]------------[ cut here ]------------ [88.036519]Call trace: [88.036523] flush_workqueue+0x3e4/0x430 [88.036528] drain_workqueue+0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546] __dev_close_many+0xcc/0x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part.0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] process_one_work+0x1d8/0x4a0 [88.036573] worker_thread+0x54/0x408 [88.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+0x10/0x20 [88.036588]---[ end trace e70de432e4d5c2c1 ]--- [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: stmmac: Borrar variable al destruir la cola de trabajo Actualmente, al suspender el controlador y detener la cola de trabajo, se verifica si la cola de trabajo no es NULL y, de ser así, se destruye. La función destroy_workqueue() drena la cola y borra la variable, pero no establece la variable de la cola de trabajo en NULL. Esto puede causar pánico en el núcleo/módulo si el código intenta borrar la cola de trabajo que no se inicializó. Este escenario es posible al reanudar el controlador suspendido en stmmac_resume(), porque no hay control para stmmac_hw_setup() fallido, que puede fallar y regresar si el motor DMA no se pudo inicializar y la cola de trabajo se inicializa después del motor DMA. • https://git.kernel.org/stable/c/5a5586112b929546e16029261a987c9197bfdfa2 https://git.kernel.org/stable/c/8e99556301172465c8fe33c7f78c39a3d4ce8462 https://git.kernel.org/stable/c/17ccd9798fe0beda3db212cfa3ebe373f605cbd6 https://git.kernel.org/stable/c/699b103e48ce32d03fc86c35b37ee8ae4288c7e3 https://git.kernel.org/stable/c/f72cf22dccc94038cbbaa1029cb575bf52e5cbc8 https://git.kernel.org/stable/c/8af411bbba1f457c33734795f024d0ef26d0963f https://access.redhat.com/security/cve/CVE-2024-26802 https://bugzilla.redhat.com/show_bug.cgi?id=2273427 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26801 – Bluetooth: Avoid potential use-after-free in hci_error_reset
https://notcve.org/view.php?id=CVE-2024-26801
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Avoid potential use-after-free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: evite el posible use-after-free en hci_error_reset Mientras se maneja el evento HCI_EV_HARDWARE_ERROR, si el controlador BT subyacente no responde, el mecanismo de reinicio de GPIO liberaría hci_dev y provocaría un error. use-after-free en hci_error_reset. • https://git.kernel.org/stable/c/c7741d16a57cbf97eebe53f27e8216b1ff20e20c https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03 https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090 https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2 https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14 https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1 https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26800 – tls: fix use-after-free on failed backlog decryption
https://notcve.org/view.php?id=CVE-2024-26800
In the Linux kernel, the following vulnerability has been resolved: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new ->async_done flag) that the memory has already been released. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tls: corrige el use-after-free en el descifrado fallido del trabajo pendiente Cuando la solicitud de descifrado va al trabajo pendiente y crypto_aead_decrypt devuelve -EBUSY, tls_do_decryption esperará hasta que se hayan completado todos los descifrados asíncronos. • https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754 https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694 https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368 https://git.kernel.org/stable/c/81be85353b0f5a7b660635634b655329b429eefe https://git.kernel.org/stable/c/1ac9fb84bc7ecd4bc6428118301d9d864d2a58d1 https://git.kernel.org/stable/c/f2b85a4cc763841843de693bbd7308fe9a2c4c89 https://git.kernel.org/stable/c/13114dc5543069f7b97991e3b79937b6da05f5b0 •