Vulnerabilidades do Linux Linux

In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Serialize channel state checks pause() and resume() read and update channel state without holding vc.lock, while the interrupt handlers update the same state under it. Take the same lock around those state checks so that request, status, and configured stay consistent. For example, pause() can observe EDMA_ST_BUSY right before the interrupt handler completes the final descriptor and moves the channel to EDMA_ST_IDLE, and then record EDMA_REQ_PAUSE on an already idle channel. No further interrupt will acknowledge the request, and since issue_pending() requires EDMA_REQ_NONE, the channel is wedged for good: terminate_all() leaves the stale request behind, so even reconfiguring the channel does not recover it. issue_pending() already runs under vc.lock, but it tests configured before taking it. Move that test under the lock as well, so configured, request, and status are evaluated as one channel-state snapshot.

In the Linux kernel, the following vulnerability has been resolved: iio: dac: ad5686: missing NULL check on match data Verify that chip_info pointer is not NULL. If a user binds the driver using driver_override via sysfs with a device name not present in the id_table or of_match_table, match data will be NULL.

In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc() When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ]

In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: validate dynamic counter attribute length RDMA_NLDEV_ATTR_STAT_HWCOUNTERS is a nested attribute whose children are consumed directly with nla_get_u32(). The top-level policy validates only the container, so it does not establish the fixed shape of each child. Require every child payload to be exactly one u32 before reading it.

In the Linux kernel, the following vulnerability has been resolved: ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_root acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed.

In the Linux kernel, the following vulnerability has been resolved: bpf: Zero queue and stack outputs on lock failure Queue and stack pop/peek helpers accept an uninitialized output buffer because the verifier expects the helper to initialize it. The empty-map error path clears the buffer, but a failed lock acquisition returns -EBUSY without writing it. Clear the output before returning -EBUSY so BPF programs cannot observe uninitialized stack contents after a failed helper call.

In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix memory leak in bpf_jit_free When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog->is_func || extra_pass is false), keeping ctx->offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data->ctx.offset, which causes a memory leak of the JIT context offsets array. Fix this by adding the missing kfree(jit_data->ctx.offset) in bpf_jit_free().

In the Linux kernel, the following vulnerability has been resolved: bpf, riscv: Fix extable handling for arena load_acquire emit_atomic_ld_st() returns 1 to have build_body() skip the zext after a sub-word load_acquire. The caller does "ret = ret ?: add_exception_handler(...)", which skips add_exception_handler() on any non-zero ret, so the extable entry is missing and a faulting PROBE_ATOMIC load_acquire oopses. REG_DONT_CLEAR_MARKER leaves rd stale on fault, and the verifier still thinks the load overwrote it, so a program can leak it through a map. Check ret >= 0 before calling add_exception_handler(), and pass rd for LOAD_ACQ so the fault zeroes rd like a PROBE_MEM load. Return ret unchanged for the zext skip.

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix offset warn check for bpf_res_spin_lock Sashiko pointed out correctly that the case statement for BPF_RES_SPIN_LOCK incorrectly checks offset for BPF_SPIN_LOCK. Fix it by checking res_spin_lock_off instead.

In the Linux kernel, the following vulnerability has been resolved: bpf: Preserve unique-field state across nested structs btf_find_struct_field() initializes a fresh seen mask for every recursive descent. Unique special fields in different levels of the same aggregate therefore do not see one another. The duplicate fields can reach btf_parse_fields(), where they trigger an invariant WARN_ON_ONCE(). A crafted user BTF can consequently trigger the warning before map creation checks capabilities. Initialize the seen mask once in btf_find_field() and pass the same pointer through struct, datasec, and nested-struct walks. This gives the entire field traversal one shared uniqueness state.

In the Linux kernel, the following vulnerability has been resolved: RDMA/erdma: Fix CEQ tasklet use-after-free on removal Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring through get_next_valid_eqe() and updates eq->dbrec through notify_eq(). erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ. free_irq() prevents another hard IRQ and waits for an in-flight handler, but it does not drain a tasklet that the handler already scheduled. The tasklet can therefore access eq->qbuf or eq->dbrec after erdma_eq_destroy() frees them. Clearing ceq_cb->ready does not synchronize with a tasklet that already passed the check at the start of erdma_ceq_completion_handler(). Kill the tasklet after free_irq(), when no handler can schedule it again, and before erdma_ceq_uninit_one() releases the EQ buffers.

In the Linux kernel, the following vulnerability has been resolved: RDMA/mana_ib: drain QP references after partial table insertion mana_table_store_ud_qp() publishes a QP at its send-queue id before inserting the receive-queue id, dropping the XArray lock between the two xa_insert_irq() calls. A concurrent completion handler can look up the QP and take a transient reference. When the second insertion fails, the rollback erased only the send-queue entry and returned, leaving both the initial table reference and the transient reference outstanding while RDMA core frees the QP, causing a use-after-free. Drain the reference as normal destruction does: drop the initial reference and wait for qp->free, releasing the QP only after every concurrent lookup returns its reference.

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix use after free in ib_query_qp() When querying a QP via the netlink flow the only synchronization mechanism for the said QP is rdma_restrack_get(), meanwhile during the QP destroy path rdma_restrack_del() is called at the end of the ib_destroy_qp_user() function which is too late, since by then the vendor specific resources for said QP would already be destroyed, and till the rdma_restrack_del() is called this QP can still be accessed, which could cause the use after free below. Fix this by moving the rdma_restrack_begin_del() to the start of the ib_destroy_qp_user(), which in turn waits for all usages of the QP to be done then removes it from the database to prevent access to it while it is being destroyed. RIP: 0010:ib_query_qp+0x15/0x50 [ib_core] Code: 48 83 05 5d 8e b9 ff 01 eb b5 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 c7 46 40 00 00 00 00 48 c7 46 78 00 00 00 00 <48> 8b 07 48 8b 80 88 01 00 00 48 85 c0 74 1a 48 83 05 54 91 b9 ff RSP: 0018:ff11000108a8f2f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ff11000108a8f370 RCX: ff11000108a8f370 RDX: 0000000000000000 RSI: ff11000108a8f3d8 RDI: 0000000000000000 RBP: ff1100010de5a000 R08: 0000000000000e80 R09: 0000000000000004 R10: ff110001057a604c R11: 0000000000000000 R12: ff11000108a8f370 R13: ff110001090e8000 R14: 0000000000000000 R15: ff110001057a602c FS: 00007f2ffd8db6c0(0000) GS:ff110008dc90b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010b9a7004 CR4: 0000000000373eb0 Call Trace: <TASK> mlx5_ib_gsi_query_qp+0x21/0x50 [mlx5_ib] mlx5_ib_query_qp+0x689/0x9d0 [mlx5_ib] ib_query_qp+0x35/0x50 [ib_core] fill_res_qp_entry_query.isra.0+0x47/0x280 [ib_core] ? __wake_up+0x40/0x50 ? netlink_broadcast_filtered+0x15a/0x550 ? kobject_uevent_env+0x562/0x710 ? ep_poll_callback+0x242/0x270 ? __nla_put+0xc/0x20 ? nla_put+0x28/0x40 ? nla_put_string+0x2e/0x40 [ib_core] fill_res_qp_entry+0x138/0x190 [ib_core] res_get_common_dumpit+0x4a5/0x800 [ib_core] ? fill_res_qp_entry_query.isra.0+0x280/0x280 [ib_core] nldev_res_get_qp_dumpit+0x1e/0x30 [ib_core] netlink_dump+0x16f/0x450 __netlink_dump_start+0x1ce/0x2e0 rdma_nl_rcv_msg+0x1d3/0x330 [ib_core] ? nldev_res_get_qp_raw_dumpit+0x30/0x30 [ib_core] rdma_nl_rcv_skb.constprop.0.isra.0+0x108/0x180 [ib_core] rdma_nl_rcv+0x12/0x20 [ib_core] netlink_unicast+0x255/0x380 ? __alloc_skb+0xfa/0x1e0 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x230 ? copy_msghdr_from_user+0xea/0x170 ___sys_sendmsg+0x7c/0xb0 ? __futex_wait+0x95/0xf0 ? __futex_wake_mark+0x40/0x40 ? futex_wait+0x67/0x100 ? futex_wake+0xac/0x1b0 __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xb90 entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix potential use after free in counter_release() When accessing a counter via the netlink path the only synchronization mechanism for the said counter is rdma_restrack_get(). Currently, rdma_restrack_del() is invoked at the end of counter_release(), which is too late, since by that point vendor-specific resources associated with the counter might already be freed. This can leave a short window where the counter remains accessible through restrack, leading to a potential use-after-free. Fix this by moving the rdma_restrack_del() call to be before the freeing of the vendor-specific resources, ensuring that the counter is removed from restrack before its internal resources are released. This guarantees that no new users hold references to a counter that is in the process of destruction.

In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix requested device removal race scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback.

In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix undefined behavior in devid_write debugfs function When for_each_pci_segment() loop completes without finding a matching segment, the pci_seg pointer is not NULL but points to an invalid memory location (the list head). Accessing pci_seg->id after the loop causes undefined behavior. Fix this by handling the successful case inside the loop and returning -EINVAL after the loop if no matching segment is found.