wifi: rtw88: pci: fix resource leak on failed NAPI setup
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: pci: fix resource leak on failed NAPI setup
rtw_pci_probe() allocates PCI resources through
rtw_pci_setup_resource() before it sets up NAPI. If
rtw_pci_napi_init() fails, the error path jumps straight to
err_pci_declaim and skips rtw_pci_destroy(), leaving the PCI
resources allocated by rtw_pci_setup_resource() behind.
Add a dedicated cleanup label for the NAPI setup failure path so probe
destroys the PCI resources.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing current
mainline k
wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on reboot
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: pci: add .shutdown callback to stop rfkill polling on reboot
Since the hardware rfkill polling was introduced, arm64 platforms can
panic with an asynchronous SError during warm reboot:
SError Interrupt on CPU8, code 0x00000000be000011 -- SError
Workqueue: events_power_efficient rfkill_poll [rfkill]
rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci]
rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core]
rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core]
ieee80211_rfkill_poll+0x3c/0x70 [mac80211]
cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211]
rfkill_poll+0x30/
wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex
mt7615_suspend() acquired the mt76 mutex and then called
cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the
same mutex via mt7615_mutex_acquire() at the top of the worker, so if
mac_work is already running and blocked on the mutex, the suspend path
deadlocks waiting for the work it holds the mutex against.
Flush scan_work and mac_work before taking the mutex, matching the
suspend paths in mt7921 and mt7925. scan_work only takes the mt76
spinlock, but moving it keeps the sequence consi
wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE copy
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE copy
mt7915_mcu_get_eeprom() copies a fixed EFUSE block into the driver's
dev->mt76.eeprom.data buffer at the offset reported by the MCU response
(res->addr, a device-controlled __le32) without checking it against the
buffer size. A malicious or malfunctioning device can report an arbitrary
address and drive a 16-byte out-of-bounds write past eeprom.data.
Reject a response whose address would place the copy outside eeprom.data
before deriving the destination pointer. Devices that echo the requested
in-bou
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7925: cancel mlo_pm_work on stop
mt7925 queues mlo_pm_work with a 5 second delay during multi-link
power-save setup and never cancels it on the stop path. If the device is
torn down inside that window, the work outlives the teardown and its timer
fires afterwards, trying to queue onto the workqueue that is already gone:
workqueue: cannot queue mt7925_mlo_pm_work [mt7925_common] on wq phy0
WARNING: kernel/workqueue.c:2283 at __queue_work+0x59/0xa0, CPU#1: swapper/1/0
call_timer_fn+0x2a/0x140
__run_timers+0x203/0x330
run_timer_softirq+0x86/0xf0
mt
wifi: mt76: mt7996: bound the device EEPROM address before the EFUSE copy
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: bound the device EEPROM address before the EFUSE copy
mt7996_mcu_get_eeprom() derives the destination of the EFUSE/EXT block
copy from the address reported by the MCU response (event->addr, a
device-controlled __le32) and clamps only the copy length, never the
destination offset into dev->mt76.eeprom.data. A malicious or
malfunctioning device can report an arbitrary address and drive an
out-of-bounds write of up to MT7996_EXT_EEPROM_BLOCK_SIZE bytes past
eeprom.data.
Reject a response whose address would place the copy outside eeprom.data
before derivin
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: fix TX DMA mapping leak for AddBA req frames
mt7996/mt7992 hand the firmware a HW MAC-TXP for AddBA req action frames
(MT_TXD7_MAC_TXD, set in mt7996_mac_write_txwi_80211()), but are otherwise
FW-TXP devices. On tx free mt76_connac_txp_skb_unmap() therefore decodes
the per-frame txp as a struct mt76_connac_fw_txp. For a MAC-TXP the
fw_txp.nbuf byte aliases the AddBA TID word (MT_TXP1_TID_ADDBA), which is
always zero, so the unmap loop runs zero times and the skb DMA mapping in
buf[1] is never unmapped. buf[1].skip_unmap is set unconditionally, so the
gen
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: validate default EEPROM firmware size
The default EEPROM firmware is parsed and copied as a full EEPROM
without checking its length. A truncated file can make the driver
read beyond the firmware buffer during variant validation or the
fallback copy.
Reject files shorter than MT7996_EEPROM_SIZE before parsing or
copying the firmware.
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: flush works in dependency order
virtio_vsock_remove() stops the virtqueues and then flushes each work
item before freeing the enclosing virtio_vsock. The current order does
not account for dependencies between those items: tx_work may queue
send_pkt_work, and send_pkt_work may queue rx_work.
In particular, send_pkt_work can set restart_rx and release tx_lock.
The remove path can then stop the queues and flush rx_work before
send_pkt_work queues it. Although the later send_pkt_work flush waits
for that producer to finish, nothing waits for the newly queued r
w1: ds28e17: reject an oversize length on an I2C block read
In the Linux kernel, the following vulnerability has been resolved:
w1: ds28e17: reject an oversize length on an I2C block read
w1_f19_i2c_master_transfer() is the master_xfer for the DS28E17 1-Wire
to I2C bridge. On an I2C_M_RECV_LEN read, it takes the length from the
device. The downstream slave puts a length byte in buf[0]. The driver
then reads that many bytes into buf[1] with w1_f19_i2c_read().
buf[0] is controlled by the device and can be 0 to 255.
w1_f19_i2c_read() only rejects a zero count. The caller buffer is
I2C_SMBUS_BLOCK_MAX + 2, so 34 bytes. A length above 32 makes the read
run past it, up to about 222 bytes out of bounds.
In the Linux kernel, the following vulnerability has been resolved:
tpm: tpm_i2c_nuvoton: disable IRQ on wait timeout
i2c_nuvoton_wait_for_stat() enables the IRQ before waiting for the
interrupt handler to report a status change. If the wait times out, or is
interrupted before the handler runs, the function returns without
balancing the enable_irq() call.
Disable the IRQ before leaving the failed wait path. Also preserve an
interrupted wait's original error code instead of converting it to
-ETIMEDOUT inside the helper.
sysctl: move the "cad_pid" entry from pid_table[] to kern_reboot_table[]
In the Linux kernel, the following vulnerability has been resolved:
sysctl: move the "cad_pid" entry from pid_table[] to kern_reboot_table[]
cad_pid is global, and kill_cad_pid() is only used in the root namespace.
However, due to pid_table_root_permissions(), a non-root user can unshare
pid/user namespaces and modify it from the child namespace. This makes no
sense and is simply wrong.
Move it to kern_reboot_table[] where it logically belongs; this ensures
that only GLOBAL_ROOT_UID can read/modify this sysctl.
Note that this patch doesn't preserve "#ifdef CONFIG_PROC_SYSCTL" around
the "cad_pid"; CONFIG_PROC_SYSCTL selects CONFIG_SYSCTL
smack: fix cred UAF in smack_file_send_sigiotask()
In the Linux kernel, the following vulnerability has been resolved:
smack: fix cred UAF in smack_file_send_sigiotask()
When inspecting the credentials of another task, objective credentials
(->real_cred, accessed with __task_cred()) must always be used.
Accessing ->cred on a non-current task is forbidden unless that task is
being created or destroyed; a task is allowed to change its own ->cred
pointer with no synchronization, and changing ->cred should only affect the
current syscall.
smack_file_send_sigiotask() was accessing both sets of credentials: First
tsk->cred, then __task_cred(tsk).
Fix it, always access the objective credentials
timekeeping: Check the return value of tk_get_aux_ts64 in __do_adjtimex()
In the Linux kernel, the following vulnerability has been resolved:
timekeeping: Check the return value of tk_get_aux_ts64 in __do_adjtimex()
If the auxiliary clock is disabled during tk_get_aux_ts64() but is enabled
before tks->clock_valid is checked, then uninitialized stackdata will be
used in the calculations and indirectly leaked to userspace.
The same race window also exists after this change and also for the core
timekeeper. But in these cases the only effect would be incorrect
adjustments and this is userspace's responsibility to avoid this.
ksmbd: fix use-after-free in oplock break notification
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in oplock break notification
smb2_oplock_break_noti() reads opinfo->conn without any lock and
dereferences it after two allocations which may sleep. When the
durable handle owning the oplock is disconnected, session_fd_check()
clears opinfo->conn and drops its conn reference under ci->m_lock, and
the last ksmbd_conn_put() frees the connection. A break triggered by
another connection that races with the teardown can then resurrect the
freed connection: ksmbd_conn_get() is a plain atomic_inc, and the
queued break work later dereferences the stale c
vlan: fix skb_under_panic and races when toggling HW VLAN offload
In the Linux kernel, the following vulnerability has been resolved:
vlan: fix skb_under_panic and races when toggling HW VLAN offload
Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or
NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(),
which dynamically changed vlandev->hard_header_len.
This causes two issues:
1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2)
read dev->hard_header_len without holding RTNL lock. Mutating
hard_header_len dynamically under RTNL creates a data race where upper
layers reserve insufficient headroom based on a stale hard_header_len,
resultin
crypto: krb5 - use kfree_sensitive() for derived key buffers
In the Linux kernel, the following vulnerability has been resolved:
crypto: krb5 - use kfree_sensitive() for derived key buffers
crypto_krb5_prepare_encryption() and crypto_krb5_prepare_checksum()
free the buffer holding the freshly derived keys with plain kfree(),
leaving the key material behind in the freed slab object.
xhci: dbgtty: Fix unregister on tty_register_driver() failure
In the Linux kernel, the following vulnerability has been resolved:
xhci: dbgtty: Fix unregister on tty_register_driver() failure
If tty_register_driver() fails, it drops the reference, but fails to set
the global dbc_tty_driver to NULL, causing the unregister to be called
again when module exits.
On module unload dbc_tty_exit() only gates its cleanup on the driver
pointer being non-NULL, so it operates on the already-freed driver:
module_init(xhci_hcd_init)
xhci_hcd_init()
xhci_dbc_init() [return value ignored]
dbc_tty_init()
tty_register_driver() fails
tty_drive
In the Linux kernel, the following vulnerability has been resolved:
crypto: qcom-rng - Allow zero as a random number
Zero is a valid random number and needs to be allowed. Otherwise the
output is distinguishable from random.
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: vsie: zero stale crypto bits
When shadowing crypto access bits from a format0 apcb (crycb 0 or 1),
the bits 64..255 are unchanged from whatever is in the vsie page in the
crycb and thus in the apcb. This gives a nested guest potential access
to a device no longer available. Zero out the remaining bits.