CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26620 – s390/vfio-ap: always filter entire AP matrix
https://notcve.org/view.php?id=CVE-2024-26620
In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: always filter entire AP matrix The vfio_ap_mdev_filter_matrix function is called whenever a new adapter or domain is assigned to the mdev. The purpose of the function is to update the guest's AP configuration by filtering the matrix of adapters and domains assigned to the mdev. When an adapter or domain is assigned, only the APQNs associated with the APID of the new adapter or APQI of the new domain are inspected. If an APQN does not reference a queue device bound to the vfio_ap device driver, then it's APID will be filtered from the mdev's matrix when updating the guest's AP configuration. Inspecting only the APID of the new adapter or APQI of the new domain will result in passing AP queues through to a guest that are not bound to the vfio_ap device driver under certain circumstances. Consider the following: guest's AP configuration (all also assigned to the mdev's matrix): 14.0004 14.0005 14.0006 16.0004 16.0005 16.0006 unassign domain 4 unbind queue 16.0005 assign domain 4 When domain 4 is re-assigned, since only domain 4 will be inspected, the APQNs that will be examined will be: 14.0004 16.0004 Since both of those APQNs reference queue devices that are bound to the vfio_ap device driver, nothing will get filtered from the mdev's matrix when updating the guest's AP configuration. • https://git.kernel.org/stable/c/48cae940c31d2407d860d87c41d5f9871c0521db https://git.kernel.org/stable/c/d6b8d034b576f406af920a7bee81606c027b24c6 https://git.kernel.org/stable/c/c69d821197611678533fb3eb784fc823b921349a https://git.kernel.org/stable/c/cdd134d56138302976685e6c7bc4755450b3880e https://git.kernel.org/stable/c/850fb7fa8c684a4c6bf0e4b6978f4ddcc5d43d11 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26618 – arm64/sme: Always exit sme_alloc() early with existing storage
https://notcve.org/view.php?id=CVE-2024-26618
In the Linux kernel, the following vulnerability has been resolved: arm64/sme: Always exit sme_alloc() early with existing storage When sme_alloc() is called with existing storage and we are not flushing we will always allocate new storage, both leaking the existing storage and corrupting the state. Fix this by separating the checks for flushing and for existing storage as we do for SVE. Callers that reallocate (eg, due to changing the vector length) should call sme_free() themselves. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/sme: salir siempre de sme_alloc() antes de tiempo con el almacenamiento existente. Cuando se llama a sme_alloc() con el almacenamiento existente y no estamos vaciando, siempre asignaremos nuevo almacenamiento, y ambos filtrarán el almacenamiento existente, almacenamiento y corrupción del estado. Solucione este problema separando los controles de descarga y de almacenamiento existente como lo hacemos con SVE. • https://git.kernel.org/stable/c/5d0a8d2fba50e9c07cde4aad7fba28c008b07a5b https://git.kernel.org/stable/c/21614ba60883eb93b99a7ee4b41cb927f93b39ae https://git.kernel.org/stable/c/e01af8e26c23a08625a3dd6c8c472a1752d76cce https://git.kernel.org/stable/c/569156e4fa347237f8fa2a7e935d860109c55ac4 https://git.kernel.org/stable/c/814af6b4e6000e574e74d92197190edf07cc3680 https://git.kernel.org/stable/c/dc7eb8755797ed41a0d1b5c0c39df3c8f401b3d9 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26615 – net/smc: fix illegal rmb_desc access in SMC-D connection dump
https://notcve.org/view.php?id=CVE-2024-26615
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix illegal rmb_desc access in SMC-D connection dump A crash was found when dumping SMC-D connections. It can be reproduced by following steps: - run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL> - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? • https://git.kernel.org/stable/c/4b1b7d3b30a6d32ac1a1dcede284e76ef8a8542d https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22 https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9 https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3e • CWE-476: NULL Pointer Dereference •
CVSS: 3.3EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26614 – tcp: make sure init the accept_queue's spinlocks once
https://notcve.org/view.php?id=CVE-2024-26614
In the Linux kernel, the following vulnerability has been resolved: tcp: make sure init the accept_queue's spinlocks once When I run syz's reproduction C program locally, it causes the following issue: pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock (. • https://git.kernel.org/stable/c/168a8f58059a22feb9e9a2dcc1b8053dbbbc12ef https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882 https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3 https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855 https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02 https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-413: Improper Resource Locking •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26612 – netfs, fscache: Prevent Oops in fscache_put_cache()
https://notcve.org/view.php?id=CVE-2024-26612
In the Linux kernel, the following vulnerability has been resolved: netfs, fscache: Prevent Oops in fscache_put_cache() This function dereferences "cache" and then checks if it's IS_ERR_OR_NULL(). Check first, then dereference. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs, fscache: Prevenir Ups en fscache_put_cache() Esta función desreferencia "caché" y luego verifica si es IS_ERR_OR_NULL(). Primero verifique y luego elimine la referencia. • https://git.kernel.org/stable/c/9549332df4ed4e761a1d41c83f2c25d28bb22431 https://git.kernel.org/stable/c/82a9bc343ba019665d3ddc1d9a180bf0e0390cf3 https://git.kernel.org/stable/c/1c45256e599061021e2c848952e50f406457e448 https://git.kernel.org/stable/c/4200ad3e46ce50f410fdda302745489441bc70f0 https://git.kernel.org/stable/c/3be0b3ed1d76c6703b9ee482b55f7e01c369cc68 •