CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26744 – RDMA/srpt: Support specifying the srpt_service_guid parameter
https://notcve.org/view.php?id=CVE-2024-26744
In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Support specifying the srpt_service_guid parameter Make loading ib_srpt with this parameter set work. The current behavior is that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/srpt: admite la especificación del parámetro srpt_service_guid. Hace que la carga de ib_srpt con este conjunto de parámetros funcione. El comportamiento actual es que configurar ese parámetro mientras se carga el módulo del kernel ib_srpt desencadena el siguiente fallo del kernel: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 Seguimiento de llamadas: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/ 0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 A flaw was foundin the Linux Kernel when specifying the srpt_service_guid parameter, which may lead to kernel crash. • https://git.kernel.org/stable/c/a42d985bd5b234da8b61347a78dc3057bf7bb94d https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82 https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4 https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8 https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f3375778 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26743 – RDMA/qedr: Fix qedr_create_user_qp error flow
https://notcve.org/view.php?id=CVE-2024-26743
In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix qedr_create_user_qp error flow Avoid the following warning by making sure to free the allocated resources in case that qedr_init_user_queue() fail. -----------[ cut here ]----------- WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? • https://git.kernel.org/stable/c/df15856132bc837b512caa36d2227d2350cf64d8 https://git.kernel.org/stable/c/5639414a52a29336ffa1ede80a67c6d927acbc5a https://git.kernel.org/stable/c/135e5465fefa463c5ec93c4eede48b9fedac894a https://git.kernel.org/stable/c/7f31a244c753aacf40b71d01f03ca6742f81bbbc https://git.kernel.org/stable/c/95175dda017cd4982cd47960536fa1de003d3298 https://git.kernel.org/stable/c/bab8875c06ebda5e01c5c4cab30022aed85c14e6 https://git.kernel.org/stable/c/5ba4e6d5863c53e937f49932dee0ecb004c65928 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-459: Incomplete Cleanup •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26742 – scsi: smartpqi: Fix disable_managed_interrupts
https://notcve.org/view.php?id=CVE-2024-26742
In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix disable_managed_interrupts Correct blk-mq registration issue with module parameter disable_managed_interrupts enabled. When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to register with blk-mq using blk_mq_map_queues(). The driver is currently calling blk_mq_pci_map_queues() which results in a stack trace and possibly undefined behavior. Stack Trace: [ 7.860089] scsi host2: smartpqi [ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1 [ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022 [ 7.963026] Workqueue: events work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010 [ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00 [ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.172818] PKRU: 55555554 [ 8.172819] Call Trace: [ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi] [ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.351193] process_one_work+0x1a7/0x360 [ 8.364462] ? create_worker+0x1a0/0x1a0 [ 8.379252] worker_thread+0x1ce/0x390 [ 8.392623] ? create_worker+0x1a0/0x1a0 [ 8.406295] kthread+0x10a/0x120 [ 8.418428] ? • https://git.kernel.org/stable/c/cf15c3e734e8d25de7b4d9170f5a69ace633a583 https://git.kernel.org/stable/c/3c31b18a8dd8b7bf36af1cd723d455853b8f94fe https://git.kernel.org/stable/c/4f5b15c15e6016efb3e14582d02cc4ddf57227df https://git.kernel.org/stable/c/b9433b25cb06c415c9cb24782599649a406c8d6d https://git.kernel.org/stable/c/5761eb9761d2d5fe8248a9b719efc4d8baf1f24a •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26741 – dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().
https://notcve.org/view.php?id=CVE-2024-26741
In the Linux kernel, the following vulnerability has been resolved: dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished(). syzkaller reported a warning [0] in inet_csk_destroy_sock() with no repro. WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash); However, the syzkaller's log hinted that connect() failed just before the warning due to FAULT_INJECTION. [1] When connect() is called for an unbound socket, we search for an available ephemeral port. If a bhash bucket exists for the port, we call __inet_check_established() or __inet6_check_established() to check if the bucket is reusable. If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num. Later, we look up the corresponding bhash2 bucket and try to allocate it if it does not exist. Although it rarely occurs in real use, if the allocation fails, we must revert the changes by check_established(). • https://git.kernel.org/stable/c/28044fc1d4953b07acec0da4d2fc4784c57ea6fb https://git.kernel.org/stable/c/729bc77af438a6e67914c97f6f3d3af8f72c0131 https://git.kernel.org/stable/c/334a8348b2df26526f3298848ad6864285592caf https://git.kernel.org/stable/c/f8c4a6b850882bc47aaa864b720c7a2ee3102f39 https://git.kernel.org/stable/c/66b60b0c8c4a163b022a9f0ad6769b0fd3dc662f •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26740 – net/sched: act_mirred: use the backlog for mirred ingress
https://notcve.org/view.php?id=CVE-2024-26740
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. • https://git.kernel.org/stable/c/53592b3640019f2834701093e38272fdfd367ad8 https://git.kernel.org/stable/c/7c787888d164689da8b1b115f3ef562c1e843af4 https://git.kernel.org/stable/c/60ddea1600bc476e0f5e02bce0e29a460ccbf0be https://git.kernel.org/stable/c/52f671db18823089a02f07efc04efdb2272ddc17 https://access.redhat.com/security/cve/CVE-2024-26740 https://bugzilla.redhat.com/show_bug.cgi?id=2273268 • CWE-833: Deadlock •