staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()
OnAuth() has two bugs in the shared-key authentication path.
When the Privacy bit is set, rtw_wep_decrypt() is called without
verifying that the frame is long enough to contain a valid WEP IV and
ICV. Inside rtw_wep_decrypt(), length is computed as:
length = len - WLAN_HDR_A3_LEN - iv_len
and then passed as (length - 4) to crc32_le(). If len is less than
WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative
and, after the implicit cast to size_t, causes crc32_le() to read far
beyo
staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop
The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each
iteration but only guards on i < pkt_len. When a malicious AP sends an
AssocResponse whose last IE has only one byte remaining in the frame
(the element_id byte lands at pkt_len-1), the loop reads pIE->length
from pframe[pkt_len], which is one byte past the allocated receive buffer.
Additionally, even when the header bytes are in bounds, pIE->length
itself can extend the data window beyond pkt_len, silently passing a
truncated IE to the handler fu
staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop
The IE parsing loop in update_beacon_info() advances by
(pIE->length + 2) each iteration but only guards on i < len.
When a malicious AP sends a Beacon whose last IE has only one byte
remaining in the frame (the element_id byte lands at len-1), the loop
reads pIE->length from one byte past the allocated receive buffer.
Additionally, even when the header bytes are in bounds, pIE->length
itself can extend the data window beyond len, passing a truncated IE
to the handler functions.
Add two guards at the top of
staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl()
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl()
Two IE parsing loops are missing the header bounds checks before they
dereference pIE->length:
- issue_assocreq() walks pmlmeinfo->network.ies to build the
association request. If the stored IE data ends with only an
element_id byte and no length byte, pIE->length is read one byte
past the end of the buffer.
- join_cmd_hdl() walks pnetwork->ies during station join and has
the same problem under the same conditions.
Both buffers are filled from AP beacon and probe-response f
staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()
Three IE/attribute parsing functions have missing bounds checks.
rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer
without verifying that the header bytes (tag + length) are within the
remaining buffer before reading them. Additionally, rtw_get_sec_ie()
compares the 4-byte WPA OUI at cnt+2 without checking that at least
6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at
cnt+6 without checking that at least 10 bytes remain.
rtw_get_wps_attr()
staging: rtl8723bs: fix OOB write in HT_caps_handler()
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB write in HT_caps_handler()
HT_caps_handler() iterates pIE->length bytes and writes into
HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct
HT_caps_element). Because pIE->length is a raw u8 from an over-the-air
802.11 AssocResponse frame and is never validated, a malicious AP can
set it up to 255, causing up to 229 bytes of out-of-bounds writes into
adjacent fields of struct mlme_ext_info.
Truncate the iteration count to the size of HT_caps.u.HT_cap using
umin() so that data from a longer-than-expected IE is silently ignored
rather
crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()
The VF2PF interrupt handler queues PF-side response work that stores a
raw pointer to per-VF state (struct adf_accel_vf_info). Currently,
adf_disable_sriov() destroys per-VF mutexes and frees vf_info without
stopping new VF2PF work or waiting for in-flight workers to complete. A
concurrently scheduled or already queued worker can then dereference
freed memory.
This manifests as a use-after-free when KASAN is enabled:
BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0
Write of size 8 at addr 000000000000
net: af_key: initialize alg_key_len for IPComp states
In the Linux kernel, the following vulnerability has been resolved:
net: af_key: initialize alg_key_len for IPComp states
pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by
allocating x->calg and copying only the algorithm name:
x->calg = kmalloc_obj(*x->calg);
if (!x->calg) {
err = -ENOMEM;
goto out;
}
strcpy(x->calg->alg_name, a->name);
x->props.calgo = sa->sadb_sa_encrypt;
Unlike the authentication (x->aalg) and encryption (x->ealg) branches of
the same function, the compression branch never initializes
calg->alg_key_len. IPComp carries no key and the allocation only
reserves sizeof(struct xfrm_algo) (i.
audit: Fix data races of skb_queue_len() readers on audit_queue
In the Linux kernel, the following vulnerability has been resolved:
audit: Fix data races of skb_queue_len() readers on audit_queue
Multiple readers access audit_queue.qlen via skb_queue_len() without
holding the queue lock or using READ_ONCE(), while kauditd writes to
this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE()
protected by a spinlock. This constitutes data races.
All affected skb_queue_len(&audit_queue) call sites:
- kauditd_thread() wait_event_freezable() condition
- audit_receive_msg() AUDIT_GET handler (s.backlog assignment)
- audit_receive() backlog check
- audit_log_start() backlog check and pr_w
fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns
In the analysis pass of $LogFile journal replay, log_replay() copies
LCNs from each action log record into an existing Dirty Page Table
(DPT) entry without bounding the destination index. A crafted NTFS
image with DPT entry lcns_follow=1 and an action log record with
lcns_follow=2 produces a kernel slab out-of-bounds write at mount
time:
BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60
Write of size 8 at addr ffff8880095e1040 by task mount
Two attacker-controlled fields can drive j+i past t
NTB: epf: Avoid calling pci_irq_vector() from hardirq context
In the Linux kernel, the following vulnerability has been resolved:
NTB: epf: Avoid calling pci_irq_vector() from hardirq context
ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive
the vector number. pci_irq_vector() calls msi_get_virq() that takes a
mutex and can therefore trigger "scheduling while atomic" splats:
BUG: scheduling while atomic: kworker/u33:0/55/0x00010001
...
Call trace:
...
schedule+0x38/0x110
schedule_preempt_disabled+0x28/0x50
__mutex_lock.constprop.0+0x848/0x908
__mutex_lock_slowpath+0x18/0x30
mutex_lock+0x4c/0x60
msi_domain_get_virq+0xe8/0x138
pci_irq_vector+0x2c/0x60
gpio: eic-sprd: use raw_spinlock_t in the irq startup path
In the Linux kernel, the following vulnerability has been resolved:
gpio: eic-sprd: use raw_spinlock_t in the irq startup path
sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller
state through sprd_eic_update(), which takes sprd_eic->lock with
spin_lock_irqsave(). The callback can be reached from irq_startup()
while setting up a requested IRQ. That path is not sleepable, but on
PREEMPT_RT a regular spinlock_t becomes a sleeping lock.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the request_threaded_irq() -> __setup_irq() ->
irq_startup() ->
gpio: sch: use raw_spinlock_t in the irq startup path
In the Linux kernel, the following vulnerability has been resolved:
gpio: sch: use raw_spinlock_t in the irq startup path
sch_irq_unmask() enables the GPIO IRQ and then updates the controller
state through sch_irq_mask_unmask(), which takes sch->lock with
spin_lock_irqsave(). The callback can be reached from irq_startup()
while setting up a requested IRQ. That path is not sleepable, but on
PREEMPT_RT a regular spinlock_t becomes a sleeping lock.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the request_threaded_irq() -> __setup_irq() ->
irq_startup() -> sch_ir
io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item
In the Linux kernel, the following vulnerability has been resolved:
io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item
commit 10dc95939817 ("io_uring/io-wq: check IO_WQ_BIT_EXIT inside work
run loop") fixed the obvious case where io_worker_handle_work() took one
exit-bit snapshot before draining pending work, but the fix stops one
level too early.
io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work
run loop, yet it still snapshots that bit once before processing a whole
dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT
after the first linked item has started, the remaining linked items
Высокий · CVSS 7.8EPSS 0,12%Нет опубликованного исправления
netpoll: fix a use-after-free on shutdown path
In the Linux kernel, the following vulnerability has been resolved:
netpoll: fix a use-after-free on shutdown path
There is a use-after-free error on netpoll, which is clearly detected by
KASAN.
BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80
Read of size 1 at addr ... by task kworker/9:1
Workqueue: events queue_process
Call Trace:
skb_dequeue+0x1e/0xb0
queue_process+0x2c/0x600
process_scheduled_works+0x4b6/0x850
worker_thread+0x414/0x5a0
Allocated by task 242:
__netpoll_setup+0x201/0x4a0
netpoll_setup+0x249/0x550
enabled_store+0x32f/0x380
ipv4: igmp: remove multicast group from hash table on device destruction
In the Linux kernel, the following vulnerability has been resolved:
ipv4: igmp: remove multicast group from hash table on device destruction
When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through
the multicast list and calls ip_ma_put() on each membership, scheduling
them for RCU reclamation. However, they are not unlinked from the device's
multicast hash table (mc_hash).
Since the device remains published in dev->ip_ptr until after
ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash
can still locate and access the multicast group after its refcount is
decremented. If the RCU callback runs and free
net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes
Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP
socket state. The sysctl is stored as an `int` but copied into the
`u32` `tp->reordering` field for new sockets, so negative writes wrap
to large values.
With `tcp_mtu_probing=2`, the wrapped value can overflow the
`tcp_mtu_probe()` size calculation and drive the MTU probing path into
an out-of-bounds read. Route `tcp_reordering` writes through
`proc_dointvec_minmax()` and require it to be at least 1. Also require
`tcp_max_reordering` to b
mfd: cros_ec: Delay dev_set_drvdata() until probe success
In the Linux kernel, the following vulnerability has been resolved:
mfd: cros_ec: Delay dev_set_drvdata() until probe success
If ec_device_probe() fails, cros_ec_class_release releases memory for the
cros_ec_dev structure. However, because the drvdata was already set,
sub-drivers like cros_ec_typec can still retrieve the stale pointer via the
platform device. This leads to a use-after-free when cros_ec_typec attempts
to access &typec->ec->ec->dev on a device that has already been released.
Move dev_set_drvdata() to ensure that the pointer is only made available
once all initialization steps have succeeded.
sysfs: cannot create duplicate f
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: zero chainstack array
sashiko reports:
looking at ebtables table
translation, could a sparse cpu_possible_mask lead to an uninitialized pointer
free?
If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible,
but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at
CPU 2, the cleanup loop will blindly decrement and call vfree() on
newinfo->chainstack[1].
Not a real-world bug, such allocation isn't expected to fail
in the first place.
netfilter: ebtables: module names must be null-terminated
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: module names must be null-terminated
We need to explicitly check the length, else we may pass non-null
terminated string to request_module().