CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47109 – neighbour: allow NUD_NOARP entries to be forced GCed
https://notcve.org/view.php?id=CVE-2021-47109
In the Linux kernel, the following vulnerability has been resolved: neighbour: allow NUD_NOARP entries to be forced GCed IFF_POINTOPOINT interfaces use NUD_NOARP entries for IPv6. It's possible to fill up the neighbour table with enough entries that it will overflow for valid connections after that. This behaviour is more prevalent after commit 58956317c8de ("neighbor: Improve garbage collection") is applied, as it prevents removal from entries that are not NUD_FAILED, unless they are more than 5s old. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vecino: permite forzar las entradas NUD_NOARP. Las interfaces GCed IFF_POINTOPOINT utilizan entradas NUD_NOARP para IPv6. Es posible llenar la tabla de vecinos con suficientes entradas para que después de eso se desborde de conexiones válidas. • https://git.kernel.org/stable/c/58956317c8de52009d1a38a721474c24aef74fe7 https://git.kernel.org/stable/c/d99029e6aab62aef0a0251588b2867e77e83b137 https://git.kernel.org/stable/c/d17d47da59f726dc4c87caebda3a50333d7e2fd3 https://git.kernel.org/stable/c/ddf088d7aaaaacfc836104f2e632b29b1d383cfc https://git.kernel.org/stable/c/7a6b1ab7475fd6478eeaf5c9d1163e7a18125c8f •
CVSS: 5.5EPSS: 0%CPEs: 13EXPL: 0CVE-2024-26629 – nfsd: fix RELEASE_LOCKOWNER
https://notcve.org/view.php?id=CVE-2024-26629
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). • https://git.kernel.org/stable/c/3097f38e91266c7132c3fdb7e778fac858c00670 https://git.kernel.org/stable/c/e2fc17fcc503cfca57b5d1dd3b646ca7eebead97 https://git.kernel.org/stable/c/ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b https://git.kernel.org/stable/c/fea1d0940301378206955264a01778700fc9c16f https://git.kernel.org/stable/c/2ec65dc6635d1976bd1dbf2640ff7f810b2f6dd1 https://git.kernel.org/stable/c/ef481b262bba4f454351eec43f024fec942c2d4c https://git.kernel.org/stable/c/10d75984495f7fe62152c3b0dbfa3f0a6b739c9b https://git.kernel.org/stable/c/a2235bc65ade40982c3d09025cdd34bc5 • CWE-393: Return of Wrong Status Code •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52608 – firmware: arm_scmi: Check mailbox/SMT channel for consistency
https://notcve.org/view.php?id=CVE-2023-52608
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Check mailbox/SMT channel for consistency On reception of a completion interrupt the shared memory area is accessed to retrieve the message header at first and then, if the message sequence number identifies a transaction which is still pending, the related payload is fetched too. When an SCMI command times out the channel ownership remains with the platform until eventually a late reply is received and, as a consequence, any further transmission attempt remains pending, waiting for the channel to be relinquished by the platform. Once that late reply is received the channel ownership is given back to the agent and any pending request is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for the reply to the new request starts. It has been observed that the spurious IRQ related to the late reply can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight lookup procedure is fooled by the fact that the message header now present in the SMT area is related to the new pending transaction, even though the real reply has still to arrive. This race-condition on the A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will have set the channel free bit before triggering the completion IRQ. Add a consistency check to validate such condition in the A2P ISR. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: comprueba la coherencia del buzón/canal SMT Al recibir una interrupción de finalización, se accede al área de memoria compartida para recuperar el encabezado del mensaje al principio y luego, si el número de secuencia del mensaje identifica una transacción que aún está pendiente, el payload relacionado también se recupera. Cuando se agota el tiempo de espera de un comando SCMI, la propiedad del canal permanece en la plataforma hasta que finalmente se recibe una respuesta tardía y, como consecuencia, cualquier intento de transmisión adicional permanece pendiente, esperando que la plataforma abandone el canal. Una vez que se recibe esa respuesta tardía, la propiedad del canal se devuelve al agente y cualquier solicitud pendiente puede continuar y sobrescribir el área SMT de la respuesta tardía recién entregada; luego comienza la espera de la respuesta a la nueva solicitud. Se ha observado que la IRQ espuria relacionada con la respuesta tardía puede asociarse erróneamente con la solicitud recién puesta en cola: cuando eso sucede, el procedimiento de búsqueda en curso de la pila SCMI se ve engañado por el hecho de que el encabezado del mensaje ahora presente en el área SMT es relacionado con la nueva transacción pendiente, aunque la respuesta real aún no ha llegado. • https://git.kernel.org/stable/c/5c8a47a5a91d4d6e185f758d61997613d9c5d6ac https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350 https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2 https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26627 – scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
https://notcve.org/view.php?id=CVE-2024-26627
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the host lock for getting busy count because host the lock never covers that. [mkp: Drop unnecessary 'busy' variables pointed out by Bart] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: Saque scsi_host_busy() del bloqueo del host para activar el controlador EH Dentro de scsi_eh_wakeup(), se llama a scsi_host_busy() y se verifica con el bloqueo del host cada vez para decidir si se produce un error. Es necesario activar el controlador kthread. Esto puede ser demasiado pesado en caso de recuperación, como por ejemplo: - N colas de hardware - la profundidad de la cola es M para cada cola de hardware - cada scsi_host_busy() itera sobre (N * M) etiquetas/solicitudes Si la recuperación se activa en caso de que todas las solicitudes están en curso, cada scsi_eh_wakeup() está estrictamente serializado, cuando se llama a scsi_eh_wakeup() para la última solicitud en curso, scsi_host_busy() se ha ejecutado (N * M - 1) veces y la solicitud se ha iterado durante ( N*M - 1) * (N * M) veces. Si tanto N como M son lo suficientemente grandes, se puede activar un bloqueo duro al adquirir el bloqueo del host, y se observa en mpi3mr (128 colas hw, profundidad de cola 8169). • https://git.kernel.org/stable/c/6eb045e092efefafc6687409a6fa6d1dabf0fb69 https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059 https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1 https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26625 – llc: call sock_orphan() at release time
https://notcve.org/view.php?id=CVE-2024-26625
In the Linux kernel, the following vulnerability has been resolved: llc: call sock_orphan() at release time syzbot reported an interesting trace [1] caused by a stale sk->sk_wq pointer in a closed llc socket. In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after calling proto_ops::release()") Eric Biggers hinted that some protocols are missing a sock_orphan(), we need to perform a full audit. In net-next, I plan to clear sock->sk from sock_orphan() and amend Eric patch to add a warning. [1] BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> Allocated by task 5167: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: llame a sock_orphan() en el momento del lanzamiento syzbot informó un rastro interesante [1] causado por un puntero sk->sk_wq obsoleto en un socket llc cerrado. En El commit ff7b11aa481f ("net: socket: set sock->sk to NULL after call proto_ops::release()") Eric Biggers insinuó que a algunos protocolos les falta un sock_orphan(), necesitamos realizar una auditoría completa. En net-next, planeo borrar sock->sk de sock_orphan() y modificar el parche de Eric para agregar una advertencia. [1] ERROR: KASAN: slab-use-after-free en list_empty include/linux/list.h:373 [en línea] ERROR: KASAN: slab-use-after-free en waitqueue_active include/linux/wait.h:127 [en línea] ERROR: KASAN: slab-use-after-free en sock_def_write_space_wfree net/core/sock.c:3384 [en línea] ERROR: KASAN: slab-use-after-free en sock_wfree+0x9a8/0x9d0 net/core/sock .c:2468 Lectura del tamaño 8 en la dirección ffff88802f4fc880 por tarea ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack .c:106 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/ list.h:373 [en línea] waitqueue_active include/linux/wait.h:127 [en línea] sock_def_write_space_wfree net/core/sock.c:3384 [en línea] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+ 0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [en línea] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/ intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq controladores/net/ethernet/intel/e1000/e1000_main.c:3860 [en línea] e1000_clean+0x4a1/0x26e0 controladores/net/ethernet/intel/e1000/e1000_main.c:3801 __ napi_poll. constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [en línea] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/ softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [en línea] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c :388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Asignado por tarea 5167: kasan_save_stack+0x33/0x50 mm/ kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [en línea] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc incluir /linux/kasan.h:201 [en línea] slab_post_alloc_hook mm/slub.c:3813 [en línea] slab_alloc_node mm/slub.c:3860 [en línea] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/ fs.h:3019 [en línea] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net /socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [en línea] __sys_socket_create net/socket.c:1659 [en línea] __sys_socket+0x14c/0x260 net/socket.c :1706 __do_sys_socket net/socket.c:1720 [en línea] __se_sys_socket net/socket.c:1718 [en línea] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [en línea ] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Liberado por la tarea 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/ common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 veneno_slab_object mm/kasan/common.c:241 [en línea] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux /kasan.h:184 [en línea] slab_free_hook mm/slub.c:2121 [en línea ---truncado--- • https://git.kernel.org/stable/c/43815482370c510c569fd18edb57afcb0fa8cab6 https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7 https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812 https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791 •