CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35938 – wifi: ath11k: decrease MHI channel buffer length to 8KB
https://notcve.org/view.php?id=CVE-2024-35938
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: decrease MHI channel buffer length to 8KB Currently buf_len field of ath11k_mhi_config_qca6390 is assigned with 0, making MHI use a default size, 64KB, to allocate channel buffers. This is likely to fail in some scenarios where system memory is highly fragmented and memory compaction or reclaim is not allowed. There is a fail report which is caused by it: kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb Workqueue: events_unbound async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x47/0x60 warn_alloc+0x13a/0x1b0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __alloc_pages_direct_compact+0xab/0x210 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0 __alloc_pages+0x32d/0x350 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __kmalloc_large_node+0x72/0x110 __kmalloc+0x37c/0x480 ? • https://git.kernel.org/stable/c/805a1cdde82fec00c7471a393f4bb437b2741559 https://git.kernel.org/stable/c/6597a6687af54e2cb58371cf8f6ee4dd85c537de https://git.kernel.org/stable/c/138fdeac75fb7512a7f9f1c3b236cd2e754af793 https://git.kernel.org/stable/c/ae5876b3b7b2243d874e2afa099e7926122087a1 https://git.kernel.org/stable/c/1cca1bddf9ef080503c15378cecf4877f7510015 https://access.redhat.com/security/cve/CVE-2024-35938 https://bugzilla.redhat.com/show_bug.cgi?id=2281819 •
CVSS: 5.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35937 – wifi: cfg80211: check A-MSDU format more carefully
https://notcve.org/view.php?id=CVE-2024-35937
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: check A-MSDU format more carefully If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: comprueba más detenidamente el formato A-MSDU Si parece que hay otra subtrama en el A-MSDU pero el encabezado no está completamente ahí, podemos terminar leyendo datos fuera de límites, sólo para descartarlo más tarde. Haga esto un poco más cuidadoso y verifique si el encabezado del subtrama puede estar presente. • https://git.kernel.org/stable/c/9eb3bc0973d084423a6df21cf2c74692ff05647e https://git.kernel.org/stable/c/5d7a8585fbb31e88fb2a0f581b70667d3300d1e9 https://git.kernel.org/stable/c/16da1e1dac23be45ef6e23c41b1508c400e6c544 https://git.kernel.org/stable/c/9ad7974856926129f190ffbe3beea78460b3b7cc https://access.redhat.com/security/cve/CVE-2024-35937 https://bugzilla.redhat.com/show_bug.cgi?id=2281821 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35936 – btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
https://notcve.org/view.php?id=CVE-2024-35936
In the Linux kernel, the following vulnerability has been resolved: btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions: - at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1 - after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: maneja el error de búsqueda del árbol de fragmentos en btrfs_relocate_sys_chunks() El caso no controlado en el bucle btrfs_relocate_sys_chunks() es una corrupción, ya que solo podría ser causado por dos condiciones imposibles: - al principio el La clave de búsqueda está configurada para buscar un elemento del árbol de fragmentos, con desplazamiento -1, esta es una búsqueda inexacta y la clave->desplazamiento contendrá el desplazamiento correcto tras una búsqueda exitosa, un elemento de árbol de fragmentos válido no puede tener un desplazamiento -1 - después de la primera búsqueda exitosa, found_key corresponde a un elemento fragmentado, el desplazamiento se reduce en 1 antes del siguiente ciclo, es imposible encontrar un elemento fragmentado allí debido a restricciones de alineación y tamaño • https://git.kernel.org/stable/c/bebd9e0ff90034875c5dfe4bd514fd7055fc7a89 https://git.kernel.org/stable/c/576164bd01bd795f8b09fb194b493103506b33c9 https://git.kernel.org/stable/c/87299cdaae757f3f41212146cfb5b3af416b8385 https://git.kernel.org/stable/c/d1ffa4ae2d591fdd40471074e79954ec45f147f7 https://git.kernel.org/stable/c/36c2a2863bc3896243eb724dc3fd4cf9aea633f2 https://git.kernel.org/stable/c/0d23b34c68c46cd225b55868bc8a269e3134816d https://git.kernel.org/stable/c/1f9212cdbd005bc55f2b7422e7b560d9c02bd1da https://git.kernel.org/stable/c/7411055db5ce64f836aaffd422396af00 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35935 – btrfs: send: handle path ref underflow in header iterate_inode_ref()
https://notcve.org/view.php?id=CVE-2024-35935
In the Linux kernel, the following vulnerability has been resolved: btrfs: send: handle path ref underflow in header iterate_inode_ref() Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: enviar: manejar el desbordamiento de la referencia de ruta en el encabezado iterate_inode_ref() Cambie BUG_ON al manejo adecuado de errores si falla la creación del búfer de ruta. Los punteros no se imprimen para no filtrar accidentalmente las direcciones del kernel. • https://git.kernel.org/stable/c/be2b6bcc936ae17f42fff6494106a5660b35d8d3 https://git.kernel.org/stable/c/024529c27c8b4b273325a169e078337c8279e229 https://git.kernel.org/stable/c/4720d590c4cb5d9ffa0060b89743651cc7e995f9 https://git.kernel.org/stable/c/2f6174fd4ccf403b42b3d5f0d1b6b496a0e5330a https://git.kernel.org/stable/c/9ae356c627b493323e1433dcb27a26917668c07c https://git.kernel.org/stable/c/c1363ed8867b81ea169fba2ccc14af96a85ed183 https://git.kernel.org/stable/c/03938619a1e718b6168ae4528e1b0f979293f1a5 https://git.kernel.org/stable/c/3c6ee34c6f9cd12802326da26631232a6 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35934 – net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()
https://notcve.org/view.php?id=CVE-2024-35934
In the Linux kernel, the following vulnerability has been resolved: net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list() Many syzbot reports show extreme rtnl pressure, and many of them hint that smc acquires rtnl in netns creation for no good reason [1] This patch returns early from smc_pnet_net_init() if there is no netdevice yet. I am not even sure why smc_pnet_create_pnetids_list() even exists, because smc_pnet_netdev_event() is also calling smc_pnet_add_base_pnetid() when handling NETDEV_UP event. [1] extract of typical syzbot reports 2 locks held by syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: reduce la presión rtnl en smc_pnet_create_pnetids_list() Muchos informes de syzbot muestran una presión rtnl extrema, y muchos de ellos insinúan que smc adquiere rtnl en la creación de netns sin una buena razón [1] Este parche regresa temprano desde smc_pnet_net_init() si aún no hay un netdevice. Ni siquiera estoy seguro de por qué existe smc_pnet_create_pnetids_list(), porque smc_pnet_netdev_event() también llama a smc_pnet_add_base_pnetid() cuando maneja el evento NETDEV_UP. [1] extracto de informes típicos de syzbot 2 bloqueos mantenidos por syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core /net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+ .+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){+++ +}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/ smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex ){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en : smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns +0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1 : ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3 }, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet. c:878 2 bloqueos retenidos por syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c: 491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}- {3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3 :3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c :809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.1 /12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+ .}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/ 0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net /core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex) {+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 • https://git.kernel.org/stable/c/bc4d1ebca11b4f194e262326bd45938e857c59d2 https://git.kernel.org/stable/c/b9117dc783c0ab0a3866812f70e07bf2ea071ac4 https://git.kernel.org/stable/c/d7ee3bf0caf599c14db0bf4af7aacd6206ef8a23 https://git.kernel.org/stable/c/a2e6bffc0388526ed10406040279a693d62b36ec https://git.kernel.org/stable/c/6e920422e7104928f760fc0e12b6d65ab097a2e7 https://git.kernel.org/stable/c/00af2aa93b76b1bade471ad0d0525d4d29ca5cc0 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •