Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wan: wanxl: Only reset hardware after BAR mapping<br /> <br /> wanxl_pci_init_one() stores the freshly allocated card in driver data<br /> before the PLX BAR is mapped. Several early probe failures then unwind<br /> through wanxl_pci_remove_one(), including failure to allocate the coherent<br /> status area or to restore the DMA mask.<br /> <br /> wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and<br /> wanxl_reset() dereferences card-&gt;plx. On those early failures card-&gt;plx<br /> is still NULL, so the error path can dereference a NULL MMIO pointer.<br /> <br /> Only issue the hardware reset once the BAR mapping exists. The remaining<br /> cleanup in wanxl_pci_remove_one() already checks whether later resources<br /> were allocated.<br /> <br /> This issue was found by a static analysis checker and confirmed by<br /> manual source review.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths<br /> <br /> In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and<br /> cifs_close_deferred_file_under_dentry(), when a pending deferred close<br /> is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to<br /> add the file to the local processing list may fail under memory pressure.<br /> The loop breaks immediately, but the cancelled work is no longer pending<br /> (it would have called _cifsFileInfo_put()), and the cfile is never added<br /> to file_head for processing. The cifsFileInfo reference and the open<br /> server handle both leak.<br /> <br /> Fix by saving the cfile that failed allocation in a local variable,<br /> breaking as before, and calling _cifsFileInfo_put() on it after<br /> releasing the lock. Any files later in the iteration are unaffected<br /> since their deferred work is still pending and will fire normally.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix infinite loop in __tipc_nl_compat_dumpit<br /> <br /> cmd-&gt;dumpit callback can return a negative errno, causing an infinite<br /> loop due to the while(len) condition. As the loop never terminates,<br /> genl_mutex is never released, and other tasks waiting on it starve in D<br /> state.<br /> <br /> Check dumpit&amp;#39;s return value, propagate it and jump to err_out on error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mctp i3c: clean up notifier and buses if driver register fails<br /> <br /> mctp_i3c_mod_init() registers the I3C bus notifier and then walks the<br /> existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL)<br /> before registering the I3C device driver. If i3c_driver_register()<br /> fails, the function returns the error directly, leaving the notifier<br /> registered and every mctp_i3c_bus object created for the existing buses<br /> allocated. The notifier is left pointing into the module that failed to<br /> load and the bus list is leaked.<br /> <br /> Mirror the module exit path on this failure: unregister the notifier and<br /> tear down the buses that were added before returning the error.<br /> <br /> This issue was identified during our ongoing static-analysis research while<br /> reviewing kernel code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: validate stream count in sctp_process_strreset_inreq()<br /> <br /> When processing a RESET_IN_REQUEST from a peer,<br /> sctp_process_strreset_inreq() derives the stream count from the<br /> parameter length but does not check whether the resulting<br /> RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN.<br /> <br /> The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes<br /> larger than the IN request header (sctp_strreset_inreq, 8 bytes).<br /> Generally, the IP payload is bounded to 65535 bytes, so the stream<br /> list cannot be large enough to trigger the overflow. However, on<br /> interfaces with MTU &gt; 65535 (e.g., loopback with IPv6 jumbograms), a<br /> stream list that fits within the incoming IN parameter can cause a<br /> __u16 overflow in sctp_make_strreset_req() when computing the OUT<br /> request size, leading to an undersized skb allocation and a kernel<br /> BUG:<br /> <br /> net/core/skbuff.c:207 skb_panic<br /> net/core/skbuff.c:2625 skb_put<br /> net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk<br /> net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req<br /> net/sctp/stream.c:655 sctp_process_strreset_inreq<br /> <br /> The local setsockopt path validates the generated reset request size.<br /> However, for an incoming-only reset, it accounts for the smaller IN<br /> request even though the peer must generate an OUT request with the same<br /> stream list. Such a request cannot be completed successfully by the<br /> peer.<br /> <br /> Reject peer IN requests whose corresponding OUT request would exceed<br /> SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an<br /> IN request that would require an oversized OUT request from the peer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel: ethosu: Fix element size accounting for cmd stream validation<br /> <br /> There are 2 issues with the element size handling in the command stream<br /> validation which result in too small of a size calculated when the<br /> element size is 16/32/64 bits.<br /> <br /> For NHWC format, the element size is simply missing from the<br /> calculation.<br /> <br /> The bitfield for the element size is different between IFM/IFM2 and<br /> OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM<br /> uses bits 1:2.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pds_core: fix auxiliary device add/del races<br /> <br /> Two paths add or delete the same slot (pf-&gt;vfs[vf_id].padev): a VF&amp;#39;s<br /> pdsc_reset_done() and the PF&amp;#39;s devlink enable_vnet/disable_vnet handler.<br /> They serialize on config_lock, but neither guards the slot under it<br /> correctly.<br /> <br /> add() registers and stores a new auxiliary device without first checking<br /> the slot, so a second add of an already-populated slot leaks the first<br /> device. del() makes that check outside config_lock, so two concurrent<br /> dels can both pass it; the first clears the slot, and the second<br /> dereferences a NULL pointer.<br /> <br /> Check and update the slot under config_lock in both paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pds_core: fix use-after-free on workqueue during remove<br /> <br /> In pdsc_remove(), the workqueue is destroyed before pdsc_teardown()<br /> is called. This ordering allows two paths to queue work on the<br /> destroyed workqueue:<br /> <br /> 1. If pdsc_teardown() -&gt; pdsc_devcmd_reset() times out, the error<br /> path in pdsc_devcmd_locked() queues health_work.<br /> <br /> 2. A NotifyQ event can trigger the ISR and queue work before free_irq()<br /> is called in pdsc_teardown().<br /> <br /> Fix by moving destroy_workqueue() after pdsc_teardown() so the<br /> workqueue outlives every queuer; destroy_workqueue() then flushes any<br /> work still pending.<br /> <br /> Draining the queued work also requires ordering the teardown so the<br /> resources that work touches are freed last:<br /> <br /> - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync()<br /> the queue&amp;#39;s work and only then clear qcq-&gt;intx, so<br /> pdsc_process_adminq()&amp;#39;s read of qcq-&gt;intx for interrupt-credit<br /> return cannot race with the clear.<br /> <br /> - Free adminqcq before notifyqcq: the shared adminq ISR is released<br /> when adminqcq is freed, and the adminq work accesses notifyqcq, so<br /> both must be stopped before notifyqcq is freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pds_core: fix deadlock between reset thread and remove<br /> <br /> pci_reset_function() acquires device_lock before performing the reset.<br /> pdsc_remove() is called by the PCI core with device_lock already held.<br /> If pdsc_pci_reset_thread() is running when pdsc_remove() is called,<br /> destroy_workqueue() will block waiting for the work to complete, while<br /> the work is blocked waiting for device_lock - deadlock.<br /> <br /> Use pci_try_reset_function() which uses pci_dev_trylock() internally.<br /> This acquires both the device lock and the PCI config access lock<br /> without blocking - if either lock is contended, it returns -EAGAIN<br /> immediately. This avoids the deadlock while also ensuring proper<br /> config space access serialization during the reset.<br /> <br /> The pci_dev_get/put calls are also removed as they were unnecessary -<br /> the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing<br /> the work completes before remove returns. The PCI core holds its<br /> reference to pci_dev throughout the entire unbind sequence.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: fix 802.1X-SHA256 call trace warning<br /> <br /> Based on wpa_auth as 1x_256 mode, need to set up<br /> "use_fwsup" with BRCMF_PROFILE_FWSUP_1X.<br /> Or it will happen trace warning when call brcmf_cfg80211_set_pmk().<br /> <br /> [ 4481.831101] ------------[ cut here ]------------<br /> [ 4481.831102] WARNING: CPU: 1 PID: 2997 at<br /> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac]<br /> [...]<br /> [ 4481.831202] Call Trace:<br /> [ 4481.831204]  <br /> [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211]<br /> [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150<br /> [ 4481.831237]  genl_rcv_msg+0x104/0x240<br /> [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211]<br /> [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150<br /> [ 4481.831259]  netlink_rcv_skb+0x4e/0x100<br /> [ 4481.831261]  genl_rcv+0x24/0x40<br /> [ 4481.831262]  netlink_unicast+0x236/0x380<br /> [ 4481.831264]  netlink_sendmsg+0x250/0x4b0<br /> [ 4481.831266]  sock_sendmsg+0x5c/0x70<br /> [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0<br /> [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0<br /> [ 4481.831272]  ___sys_sendmsg+0x86/0xd0<br /> [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0<br /> [ 4481.831276]  ? preempt_count_add+0x6a/0xa0<br /> [ 4481.831279]  ? sock_has_perm+0x82/0xa0<br /> [ 4481.831280]  __sys_sendmsg+0x57/0xa0<br /> [ 4481.831282]  do_syscall_64+0x38/0x90<br /> [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 4481.831286] RIP: 0033:0x7fd270d369b4

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffers<br /> <br /> CCS read/write buffers are freed during BO destruction. In some cases,<br /> BOs may be destroyed after the device is unbound but while the DRM<br /> structure remains valid, leading to NULL pointer dereferences when<br /> accessing device resources.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 9376 Comm: xe_pat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy)<br /> RIP: 0010:xe_sriov_vf_ccs_rw_update_bb_addr+0x4d/0xa0 [xe]<br /> RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246<br /> RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888<br /> RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888<br /> R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000<br /> FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> xe_migrate_ccs_rw_copy_clear+0x98/0x120 [xe]<br /> xe_sriov_vf_ccs_detach_bo+0x2c/0x60 [xe]<br /> xe_ttm_bo_delete_mem_notify+0xc8/0xe0 [xe]<br /> ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm]<br /> ttm_bo_release+0x29e/0x2d0 [ttm]<br /> ttm_bo_fini+0x39/0x70 [ttm]<br /> xe_gem_object_free+0x1f/0x30 [xe]<br /> drm_gem_object_free+0x1d/0x40<br /> ttm_bo_vm_close+0x5f/0x90 [ttm]<br /> remove_vma+0x2c/0x70<br /> tear_down_vmas+0x63/0xf0<br /> exit_mmap+0x20d/0x3f0<br /> __mmput+0x45/0x170<br /> mmput+0x31/0x40<br /> do_exit+0x2ba/0xac0<br /> do_group_exit+0x2d/0xb0<br /> __x64_sys_exit_group+0x18/0x20<br /> x64_sys_call+0x14a0/0x2390<br /> do_syscall_64+0xdd/0x640<br /> ? count_memcg_events+0xea/0x240<br /> ? handle_mm_fault+0x1ec/0x2f0<br /> <br /> (cherry picked from commit 1ae415a6eefe5004954a1d352b1718faca8844ef)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht()<br /> <br /> mt76_connac_get_eht_phy_cap routine can theoretically return NULL so<br /> check cap pointer before dereferencing it.