CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26748 – usb: cdns3: fix memory double free when handle zero packet
https://notcve.org/view.php?id=CVE-2024-26748
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix memory double free when handle zero packet 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request); Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again. Log: [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdns3: corrige la memoria doblemente libre cuando se maneja el paquete cero 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, solicitud 832); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (solicitud->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, solicitud); El controlador agrega una solicitud de paquete cero adicional cuando pone en cola un paquete, cuya longitud mod tamaño máximo del paquete es 0. Cuando se complete la transferencia, ejecute la línea 831, usb_gadget_giveback_request() liberará esta solicitud. • https://git.kernel.org/stable/c/7733f6c32e36ff9d7adadf40001039bf219b1cbe https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7 https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48 https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8 https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019 https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3 https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a66 •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26747 – usb: roles: fix NULL pointer issue when put module's reference
https://notcve.org/view.php?id=CVE-2024-26747
In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue when put module's reference In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: roles: soluciona el problema del puntero NULL al colocar la referencia del módulo. • https://git.kernel.org/stable/c/5c54fcac9a9de559b444ac63ec3cd82f1d157a0b https://git.kernel.org/stable/c/7b169e33a3bc9040e06988b2bc15e83d2af80358 https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1 https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913 https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734 https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef42136 • CWE-476: NULL Pointer Dereference •
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: 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 •