CVSS: 2.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52620 – netfilter: nf_tables: disallow timeout for anonymous sets
https://notcve.org/view.php?id=CVE-2023-52620
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow timeout for anonymous sets Never used from userspace, disallow these parameters. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: no permite el tiempo de espera para conjuntos anónimos Nunca se usa desde el espacio de usuario, no permita estos parámetros. A vulnerability was found in netfilter/nf_tables componets of Linux Kernel allows an userspace to set timeouts for anonymous sets, which are not intended to be used this way. This could lead to unexpected behaviour or security issues. • https://git.kernel.org/stable/c/116b0e8e4673a5faa8a739a19b467010c4d3058c https://git.kernel.org/stable/c/49ce99ae43314d887153e07cec8bb6a647a19268 https://git.kernel.org/stable/c/6f3ae02bbb62f151b19162d5fdc9fe3d48450323 https://git.kernel.org/stable/c/00b19ee0dcc1aef06294471ab489bae26d94524e https://git.kernel.org/stable/c/b7be6c737a179a76901c872f6b4c1d00552d9a1b https://git.kernel.org/stable/c/e26d3009efda338f19016df4175f354a9bd0a4ab https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://lists.debian.org/debian-lts-announce/2024&# • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26641 – ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
https://notcve.org/view.php?id=CVE-2024-26641
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() syzbot found __ip6_tnl_rcv() could access unitiliazed data [1]. Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head. [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ip6_tunnel: asegúrese de extraer el encabezado interno en __ip6_tnl_rcv(). El syzbot encontró que __ip6_tnl_rcv() podía acceder a datos unificados [1]. Llame a pskb_inet_may_pull() para solucionar este problema e inicialice la variable ipv6h después de esta llamada, ya que puede cambiar skb->head. [1] ERROR: KMSAN: valor uninit en __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea] ERROR: KMSAN: valor uninit en INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea] ERROR: KMSAN: uninit -valor en IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea] INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea] IP6_ECN_decapsulate+0x7df/0x1e50 include/ net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv 6/ip6_tunnel.c:888 gre_rcv +0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [en línea] NF_HOOK include/linux/netfilter.h:314 [en línea] ip6_input+0x15d/0x 430 netos /ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [en línea] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [en línea] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [en línea] __netif_receive_skb+0x1a6/0x5a0 net/core/dev. c:5646 netif_receive_skb_internal net/core/dev.c:5732 [en línea] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers /net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0x786/ 0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xd0 fs/read _escribir .c:652 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en: slab_post_alloc_hook+0x129/0xa 70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [en línea] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net /core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [en línea] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [en línea] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common. c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 No contaminado 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/ 2023 • https://git.kernel.org/stable/c/0d3c703a9d1723c7707e0680019ac8ff5922db42 https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080 https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0 https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8 https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6 https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-20: Improper Input Validation •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52619 – pstore/ram: Fix crash when setting number of cpus to an odd number
https://notcve.org/view.php?id=CVE-2023-52619
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Fix crash when setting number of cpus to an odd number When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pstore/ram: soluciona el fallo al establecer el número de CPU en un número impar. Cuando el número de núcleos de CPU se ajusta a 7 u otros números impares, el tamaño de la zona se convertirá en un número impar. La dirección de la zona se convertirá en: dirección de zona0 = BASE dirección de zona1 = BASE + tamaño_zona dirección de zona2 = BASE + tamaño_zona*2 ... La dirección de zona1/3/5/7 se asignará a va no alineada . • https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4 https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10 https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542 https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.3EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52618 – block/rnbd-srv: Check for unlikely string overflow
https://notcve.org/view.php?id=CVE-2023-52618
In the Linux kernel, the following vulnerability has been resolved: block/rnbd-srv: Check for unlikely string overflow Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: block/rnbd-srv: Comprueba si hay un desbordamiento de cadena improbable. Dado que "dev_search_path" técnicamente puede ser tan grande como PATH_MAX, existía el riesgo de truncamiento al copiarlo y una segunda cadena en " full_path" ya que también tenía un tamaño PATH_MAX. Las compilaciones W=1 informaban esta advertencia: drivers/block/rnbd/rnbd-srv.c: En función 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: advertencia: '% La salida de la directiva s se puede truncar escribiendo hasta 254 bytes en una región de tamaño entre 0 y 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ En la función 'rnbd_srv_get_full_path', insertada desde 'process_msg_open.isra' en drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block /rnbd/rnbd-srv.c:616:17: nota: 'snprintf' genera entre 2 y 4351 bytes en un destino de tamaño 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~ ~~~~~~~~~~~~~~~~~~~ Para solucionar este problema, verifique incondicionalmente el truncamiento (como ya se hizo en el caso en el que "%SESSNAME%" estaba presente). • https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7 https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7 https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827 https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339 https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52617 – PCI: switchtec: Fix stdev_release() crash after surprise hot remove
https://notcve.org/view.php?id=CVE-2023-52617
In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). • https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355 https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8 https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3 https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693 https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66 https://lists.debian.org/debian-lts-announce/2024/06/ •