| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net: hsr: fix memory leak on slave unregistration by removing synced VLANs
When an HSR master device is brought UP, it auto-adds VLAN 0 via
vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B).
If a slave device is later unregistered while HSR is active (e.g., during
netns cleanup or interface destruction), hsr_del_port() is called to
detach the slave port from the HSR master. However, hsr_del_port() currently
does not delete the VLAN IDs that were synced to the slave device by HSR.
As a result, the slave device retains a refcount on VID 0 (and any other
synced VLANs). When the slave device is destroyed, its vlan_info /
vlan_vid_info structure remains allocated, leading to a memory leak.
Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in
hsr_del_port() before unlinking slave A or slave B ports, matching the
propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid()
and the cleanup behavior in bonding and team drivers. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffers
CCS read/write buffers are freed during BO destruction. In some cases,
BOs may be destroyed after the device is unbound but while the DRM
structure remains valid, leading to NULL pointer dereferences when
accessing device resources.
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 9376 Comm: xe_pat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy)
RIP: 0010:xe_sriov_vf_ccs_rw_update_bb_addr+0x4d/0xa0 [xe]
RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246
RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888
RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888
R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000
FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0
PKRU: 55555554
Call Trace:
<TASK>
xe_migrate_ccs_rw_copy_clear+0x98/0x120 [xe]
xe_sriov_vf_ccs_detach_bo+0x2c/0x60 [xe]
xe_ttm_bo_delete_mem_notify+0xc8/0xe0 [xe]
ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm]
ttm_bo_release+0x29e/0x2d0 [ttm]
ttm_bo_fini+0x39/0x70 [ttm]
xe_gem_object_free+0x1f/0x30 [xe]
drm_gem_object_free+0x1d/0x40
ttm_bo_vm_close+0x5f/0x90 [ttm]
remove_vma+0x2c/0x70
tear_down_vmas+0x63/0xf0
exit_mmap+0x20d/0x3f0
__mmput+0x45/0x170
mmput+0x31/0x40
do_exit+0x2ba/0xac0
do_group_exit+0x2d/0xb0
__x64_sys_exit_group+0x18/0x20
x64_sys_call+0x14a0/0x2390
do_syscall_64+0xdd/0x640
? count_memcg_events+0xea/0x240
? handle_mm_fault+0x1ec/0x2f0
(cherry picked from commit 1ae415a6eefe5004954a1d352b1718faca8844ef) |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7925: fix crash in reset link replay
During reset recovery, mt7925_vif_connect_iter() replays firmware state
for links tracked in mvif->valid_links. After MLO link changes or MCU
timeout recovery, the driver bitmap can temporarily contain a link whose
mac80211 bss_conf has already gone away.
This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching
the crash where x1, the second argument, is NULL:
pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib]
lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common]
x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080
Call trace:
mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib]
mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common]
mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common]
Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA
reset replay is unchanged because the helper still returns &vif->bss_conf
for the legacy link. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap()
mt76_connac_get_he_phy_cap routine can theoretically return NULL so
check cap pointer before dereferencing it. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv()
mt76_connac_get_he_phy_cap routine can theoretically return NULL so
check cap pointer before dereferencing it. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: guard HE capability lookups
mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after
checking HE support, then dereference the HE PHY capability returned by
mt76_connac_get_he_phy_cap(). That helper can return NULL when no
capability entry matches the vif type.
Fetch the capability before appending the TLV and skip the HE-specific
setup when no matching capability is available. |
| In the Linux kernel, the following vulnerability has been resolved:
net: mctp i3c: clean up notifier and buses if driver register fails
mctp_i3c_mod_init() registers the I3C bus notifier and then walks the
existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL)
before registering the I3C device driver. If i3c_driver_register()
fails, the function returns the error directly, leaving the notifier
registered and every mctp_i3c_bus object created for the existing buses
allocated. The notifier is left pointing into the module that failed to
load and the bus list is leaked.
Mirror the module exit path on this failure: unregister the notifier and
tear down the buses that were added before returning the error.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code. |
| In the Linux kernel, the following vulnerability has been resolved:
pds_core: fix use-after-free on workqueue during remove
In pdsc_remove(), the workqueue is destroyed before pdsc_teardown()
is called. This ordering allows two paths to queue work on the
destroyed workqueue:
1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error
path in pdsc_devcmd_locked() queues health_work.
2. A NotifyQ event can trigger the ISR and queue work before free_irq()
is called in pdsc_teardown().
Fix by moving destroy_workqueue() after pdsc_teardown() so the
workqueue outlives every queuer; destroy_workqueue() then flushes any
work still pending.
Draining the queued work also requires ordering the teardown so the
resources that work touches are freed last:
- In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync()
the queue's work and only then clear qcq->intx, so
pdsc_process_adminq()'s read of qcq->intx for interrupt-credit
return cannot race with the clear.
- Free adminqcq before notifyqcq: the shared adminq ISR is released
when adminqcq is freed, and the adminq work accesses notifyqcq, so
both must be stopped before notifyqcq is freed. |
| In the Linux kernel, the following vulnerability has been resolved:
pds_core: fix deadlock between reset thread and remove
pci_reset_function() acquires device_lock before performing the reset.
pdsc_remove() is called by the PCI core with device_lock already held.
If pdsc_pci_reset_thread() is running when pdsc_remove() is called,
destroy_workqueue() will block waiting for the work to complete, while
the work is blocked waiting for device_lock - deadlock.
Use pci_try_reset_function() which uses pci_dev_trylock() internally.
This acquires both the device lock and the PCI config access lock
without blocking - if either lock is contended, it returns -EAGAIN
immediately. This avoids the deadlock while also ensuring proper
config space access serialization during the reset.
The pci_dev_get/put calls are also removed as they were unnecessary -
the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing
the work completes before remove returns. The PCI core holds its
reference to pci_dev throughout the entire unbind sequence. |
| Microsoft Dynamics Business Central/NAV Information Disclosure Vulnerability |
| .NET Denial of Service Vulnerability |
| .NET Denial of Service Vulnerability |
| Windows Printing Service Spoofing Vulnerability |
| Microsoft Message Queuing (MSMQ) Elevation of Privilege Vulnerability |
| Microsoft Azure Kubernetes Service Confidential Container Elevation of Privilege Vulnerability |
| Microsoft Azure File Sync Elevation of Privilege Vulnerability |
| Microsoft WDAC OLE DB provider for SQL Server Remote Code Execution Vulnerability |
| Microsoft Office OneNote Remote Code Execution Vulnerability |
| Microsoft Outlook Remote Code Execution Vulnerability |
| Windows DNS Information Disclosure Vulnerability |
