Vulnerabilidades de linux-riscv-7.0 · Página 135

wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets

In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: clamp assoc request/response lengths before subtracting IE offsets ath6kl_cfg80211_connect_event() subtracts fixed IE offsets from assoc_req_len (-= 4) and assoc_resp_len (-= 6), both u8, with no lower bound. The aggregate check recently added to ath6kl_wmi_connect_event_rx() bounds the declared lengths from above (their sum must fit the received event), but an assoc request/response shorter than its fixed offset still underflows here: the u8 wraps to ~250, and cfg80211_connect_result() / cfg80211_roamed() then treat that wrapped value as the IE length and cop

• Actualiza a 7.0.0-42.42.1~24.04.1

wifi: mt76: mt7925: cancel pending mlo_pm_work

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: cancel pending mlo_pm_work If the device is reset, suspended or unregistered within that window, the pending work can still run and access vif/bss data that may already be freed, or send MCU commands while the firmware is not available. Add cancel_delayed_work_sync(&dev->mlo_pm_work) in all relevant teardown and suspend paths: - mt7925_mac_reset_work() (chip reset recovery) - mt7925e_unregister_device() (PCIe unbind) - mt7925_pci_suspend() (PCIe bus suspend) - mt7925_suspend() (mac80211 suspend) - mt7925u_suspend(

• Actualiza a 7.0.0-42.42.1~24.04.1

media: staging/ipu7: fix async notifier UAF on probe error path

In the Linux kernel, the following vulnerability has been resolved: media: staging/ipu7: fix async notifier UAF on probe error path isys_register_devices() registers the V4L2 async notifier via isys_notifier_init(). If a subsequent probe step such as isys_fw_log_init() fails, isys_probe() jumps to the out_cleanup label which only calls isys_unregister_devices(). That helper tears down the video devices, subdevices, V4L2 device and media device, but never unregisters or cleans up the async notifier. As a result the notifier stays chained in the global notifier_list while the enclosing struct ipu7_isys is freed by devres, leading to list cor

• Actualiza a 7.0.0-42.42.1~24.04.1

sched/core: Handle pick_task() releasing the rq lock

In the Linux kernel, the following vulnerability has been resolved: sched/core: Handle pick_task() releasing the rq lock Core scheduling's pick_next_task() breaks when a ->pick_task() implementation can release the rq lock. The selection state derived on entry is only valid while the lock is held continuously. Once a pick can drop the lock, an interleaving selection can invalidate all of it: the single-CPU fast path can commit an uncookied pick although the core went cookied during the release, and forceidle committed by the interleaving selection skews the restarted pass's accounting. Fix it by restarting the whole selection when a pick r

• Actualiza a 7.0.0-42.42.1~24.04.1

sched/core: Make core-sched flips wait for in-flight selections

In the Linux kernel, the following vulnerability has been resolved: sched/core: Make core-sched flips wait for in-flight selections Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was. Count in-flight core-wide selections in th

• Actualiza a 7.0.0-42.42.1~24.04.1

sched_ext: Replace SCX_RQ_BAL_KEEP with a dispatch verdict return

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Replace SCX_RQ_BAL_KEEP with a dispatch verdict return SCX_RQ_BAL_KEEP tells the pick to keep running the previous task, a leftover from when balancing and picking were separate operations. An rq-level flag only works while dispatches and picks pair up one to one, which core scheduling breaks: selections interleave through dispatch's lock drops and a pick can consume a stale flag, keeping a task that has since been dequeued. Fixing core scheduling support requires the decision to travel with the dispatch that made it. Make scx_dispatch_sched() and balance_one() r

sched_ext: Fix this_rq() assumptions in dispatch kfuncs

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix this_rq() assumptions in dispatch kfuncs Under core scheduling, dispatch runs from within the core-wide pick and can target a sibling rq, so ops.dispatch() may execute on a CPU different from the dispatched rq's. Several kfunc paths assumed the two always coincide: - scx_dsq_move() decided whether an rq lock is held by testing this_rq()'s rq flags and lock-danced accordingly. A dispatch for a sibling took the unlocked-context branch and acquired the source rq lock on top of the already held dispatched rq lock which could deadlock. - scx_bpf_sub_dispat

sched_ext: Fix rq->core_pick corruption under core scheduling

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix rq->core_pick corruption under core scheduling Core scheduling's pick_next_task() picks what to run on every SMT sibling of the core in a single pass under the shared core-wide rq lock. The selection state is consistent only while the lock is held continuously, so ->pick_task() originally could not release it. However, since 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()"), sched_ext runs dispatch from inside the pick and dispatching can drop the rq lock. To support this, pick_next_task() has been updated to restart the whole selection when

scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables()

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fill in DMA padding bytes in scsi_alloc_sgtables() During fuzz testing, the following issue was discovered: BUG: KMSAN: uninit-value in __dma_map_sg_attrs+0x217/0x310 __dma_map_sg_attrs+0x217/0x310 dma_map_sg_attrs+0x4a/0x70 ata_qc_issue+0x9f8/0x1420 __ata_scsi_queuecmd+0x1657/0x1740 ata_scsi_queuecmd+0x79a/0x920 scsi_queue_rq+0x4472/0x4f40 blk_mq_dispatch_rq_list+0x1cca/0x3ee0 __blk_mq_sched_dispatch_requests+0x458/0x630 blk_mq_sched_dispatch_requests+0x15b/0x340 __blk_mq_run_hw_queue+0xe5/0x250 __blk_mq_delay_run_hw_queue+0x138/0x780 blk_mq_run_hw

• Actualiza a 7.0.0-42.42.1~24.04.1

scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock

In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock fnic_fcoe_process_vlan_resp() allocates a VLAN descriptor with kzalloc_obj() (default GFP_KERNEL) while holding vlans_lock via spin_lock_irqsave(). GFP_KERNEL may sleep, which is not allowed in this atomic context and can trigger a sleeping-from-invalid-context warning or deadlock. Pass GFP_ATOMIC so the allocation is safe under the IRQ-safe spinlock.

• Actualiza a 7.0.0-42.42.1~24.04.1

RISC-V: KVM: Fix PMU event info array size overflow

In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Fix PMU event info array size overflow SBI PMU EVENT_GET_INFO stores guest-controlled num_events * sizeof(*einfo) in a 32-bit integer. On RV64, num_events = 0x10000001 makes 0x100000010 truncate to 16. KVM then allocates one entry but loops over the original num_events, causing out-of-bounds reads and writes. A nested guest triggered: BUG: KASAN: slab-out-of-bounds in kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 Read of size 4 at addr ff600000074d46b0 by task init/1 Call Trace: [<ffffffff8006471c>] kvm_riscv_vcpu_pmu_event_info+0xa4/0x142 [<ffffffff800690c0>] kvm_

• Actualiza a 7.0.0-42.42.1~24.04.1

remoteproc: scp: Fix device reference leak on failed lookup

In the Linux kernel, the following vulnerability has been resolved: remoteproc: scp: Fix device reference leak on failed lookup Make sure to drop the reference taken to the SCP device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away.

• Actualiza a 7.0.0-42.42.1~24.04.1

qede: Fix NULL pointer dereference in TPA fragment processing

In the Linux kernel, the following vulnerability has been resolved: qede: Fix NULL pointer dereference in TPA fragment processing Under memory pressure, the qede driver encounters NULL pointer dereferences when processing TPA continuation fragments. Commit 8a8633978b84 ("qede: Add build_skb() support.") accidentally dropped the assignment of tpa_info->buffer.data in qede_tpa_start(). When memory pressure causes an SKB allocation failure in qede_tpa_start(), the driver sets tpa_start_fail = true and attempts to recycle the physical page later in qede_tpa_end() via qede_reuse_page(). However, because buffer.data was left uninitialized (NULL

• Actualiza a 7.0.0-42.42.1~24.04.1

RDMA/cxgb4: Cancel reg_work before freeing device on remove

In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Cancel reg_work before freeing device on remove c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device. Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case. This issue was found by an in-house static analysis tool.

• Actualiza a 7.0.0-42.42.1~24.04.1

RDMA/ionic: Embed counter driver data in rdma_counter allocation

In the Linux kernel, the following vulnerability has been resolved: RDMA/ionic: Embed counter driver data in rdma_counter allocation Commit 7e53b31acc7f ("RDMA/core: Create and destroy rdma_counter using rdma_zalloc_drv_obj()") requires drivers implementing counter ops to embed struct rdma_counter in a driver-specific struct, register its size via INIT_RDMA_OBJ_SIZE, and provide a counter_init callback. The ionic driver was merged without this adaptation, causing a NULL pointer dereference in alloc_and_bind() since rdma_zalloc_drv_obj() allocates zero bytes when size_rdma_counter is unset. Consolidate struct ionic_counter into a new struc

• Actualiza a 7.0.0-42.42.1~24.04.1

RDMA/ucma: Lock the handler in ucma_set_ib_path()

In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_set_ib_path() ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */ mutex_unlock(&ctx->file->mut); /* file B */ wake_up_interruptible(&ctx->file->poll_wait); /* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_l

• Actualiza a 7.0.0-42.42.1~24.04.1

RDMA/ucma: Lock the handler in ucma_write_cm_event()

In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_write_cm_event() ctx->file may only be changed under the handler lock and the xa_lock, which is what stops uevents being queued for a ctx while ucma_migrate_id() moves it to another file. The CM core takes that lock before invoking ucma_event_handler(), but the write() paths that queue uevents themselves do not. ucma_write_cm_event() re-reads ctx->file for each of its four dereferences, so ucma_migrate_id() can swap it mid-sequence: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* f

• Actualiza a 7.0.0-42.42.1~24.04.1

RDMA/uverbs: Add UVERBS_ATTR_UHW to UVERBS_METHOD_REG_MR

In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Add UVERBS_ATTR_UHW to UVERBS_METHOD_REG_MR The original commit missed that three drivers (mthca, irdma, siw) have UHW data associated with reg_mr that cannot be passed through the ioctl. They also assume that the udata cannot be NULL, so failing to pass a valid udata can trigger a NULL udata crash in those drivers. This never happens in real systems since in rdma-core ibv_cmd_reg_mr_ex() does not accept a udata and those three drivers don't use it, however a malicious userspace could trigger it.

• Actualiza a 7.0.0-42.42.1~24.04.1

regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer

In the Linux kernel, the following vulnerability has been resolved: regulator: as3722_get_regulator_dt_data: fix premature of_node_put leaving dangling of_node pointer In as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np, which is then assigned to pdev->dev.of_node. The function immediately calls of_node_put(np), releasing the reference and leaving pdev->dev.of_node as a dangling pointer. Remove the of_node_put(np) call to let the device hold the reference.

• Actualiza a 7.0.0-42.42.1~24.04.1

ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page()

In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page() ring_buffer_alloc_read_page() is racy with ring_buffer_subbuf_order_set, it can allocate a reader page with an outdated order. This isn't a big issue, the user can still re-allocate a new reader page and try again. However, what is more problematic is if the value of subbuf_order changes in the middle of ring_buffer_alloc_read_page(). In that case, bpage->order might not match the actual allocated memory. Use bpage->order for the allocation to prevent this race.

• Actualiza a 7.0.0-42.42.1~24.04.1