In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO
hwsim_tx_info_frame_received_nl() casts the HWSIM_ATTR_TX_INFO payload
to a struct hwsim_tx_rate * and unconditionally reads
IEEE80211_TX_MAX_RATES entries (8 bytes) from it. The policy only bounds
the attribute from above (NLA_BINARY .len is a maximum) and the op sets
GENL_DONT_VALIDATE_STRICT, so a short or zero-length attribute is
accepted and the loop reads past the payload.
Require the exact length in the policy, so a malformed attribute is
rejected before the handler runs.
drm/gma500: return errors from Oaktrail HDMI I2C reads
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: return errors from Oaktrail HDMI I2C reads
xfer_read() waits for the HDMI I2C transaction to reach
I2C_TRANSACTION_DONE, but it ignores both timeout and signal returns from
wait_for_completion_interruptible_timeout(). If the interrupt never
advances the transaction state, the loop can wait forever.
Return -ETIMEDOUT when the completion wait expires, propagate interrupted
waits, and make the I2C master_xfer callback return the first transfer
error instead of reporting a successful message count.
ima: return error early if file xattr cannot be changed
In the Linux kernel, the following vulnerability has been resolved:
ima: return error early if file xattr cannot be changed
During early boot, the filesystem is read-only and any changes
to xattrs are not allowed. This fails in case of ext4 because
changing xattr starts an ext4 transaction which fails with the
following warning.
WARNING: fs/ext4/ext4_jbd2.c:75 at ext4_journal_check_start+0x63/0xa0 [ext4], CPU#1: systemd-sysroot/561
CPU: 1 UID: 0 PID: 561 Comm: systemd-sysroot Not tainted 6.19.12-1-default #1 PREEMPT(voluntary) openSUSE Tumbleweed c2dfc3c9d9f6f1233251c5d4410574fe82a348ee
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
mmc: core: Add validation for host-provided max_segs
In the Linux kernel, the following vulnerability has been resolved:
mmc: core: Add validation for host-provided max_segs
The max_segs field is of type unsigned short, and if a host driver
sets an excessively large value, it may be truncated to zero. This
can cause mmc_alloc_sg() to call kmalloc_objs() with a zero size
allocation request, which leads to undefined behavior.
Under the SLUB allocator, kmalloc(0) returns a special pointer
(ZERO_SIZE_PTR). The subsequent 'if (sg)' check will evaluate to
true, and sg_init_table() will then attempt to access invalid memory,
resulting in a crash:
dwmmc_rockchip 2a310000.mmc: Successfully tuned pha
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_port: recognize UPIO_AU
My MIPS Alchemy systems generate the following warning during
probe of the 8250 driver:
WARNING: drivers/tty/serial/8250/8250_port.c:462 at set_io_from_upio+0xfc/0x124, CPU#0: swapper/0/1
Unsupported UART type 4
[...]
[<80521d40>] set_io_from_upio+0xfc/0x124
[<80521dfc>] serial8250_set_defaults+0x94/0xe0
[<80520fb4>] serial8250_register_8250_port+0x288/0x51c
[<805214ec>] serial8250_probe+0x160/0x1e8
[<8053b5f0>] platform_probe+0x64/0x90
The least invasive fix is to recognize UPIO_AU (type 4) in set_io_from_upio()
and do nothing, since
media: chips-media: wave5: Add range checks for dec_output_info
In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Add range checks for dec_output_info
If the driver's dec_output_info contains invalid data the driver can
write in invalid memory. Add a range check for that.
This fixes this smatch error:
drivers/media/platform/chips-media/wave5/wave5-vpuapi.c:588 wave5_vpu_dec_get_output_info() error: buffer overflow 'inst->frame_buf' 64 <= 127
net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: remove stale rcu_barrier() in br_multicast_dev_del()
This rcu_barrier() came from a time call_rcu() calls were used in
net/bridge/br_multicast.c.
Now kfree_rcu() is there, we can remove this problematic rcu_barrier()
which causes extreme RTNL pressure in many syzbot reports.
INFO: task syz-executor:77945 is blocked on a mutex likely owned by task kworker/u1024:5:36537.
task:kworker/u1024:5 state:D stack:24616 pid:36537 tgid:36537 ppid:2 task_flags:0x4208060 flags:0x00080000 last_sleep:612797637337
Workqueue: netns cleanup_net
Call Trace:
<TASK>
[<ffff
In the Linux kernel, the following vulnerability has been resolved:
ntfs3: handle set_blocksize failures
ntfs3 uses buffer_heads, which don't handle block size > PAGE_SIZE well.
Without this, mounting we will hit the
BUG_ON(offset >= folio_size(folio));
in folio_set_bh on the first __bread_gfp call.
In the Linux kernel, the following vulnerability has been resolved:
isofs: handle set_blocksize failures
isofs uses buffer_heads, which don't handle block size > PAGE_SIZE well.
Without this, mounting we will hit the
BUG_ON(offset >= folio_size(folio));
in folio_set_bh on the first __bread_gfp call.
irqchip/gic-v5: Immediately exec priority drop following activate
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v5: Immediately exec priority drop following activate
With GICv5 an interrupt of equal or lower priority cannot be signalled
until there has been a priority drop. This is done via the GIC CDEOI
system instruction. Once this has been executed, the hardware is able
to signal the next interrupt if there is one.
As all interrupts are programmed to have the same priority, no new
interrupts can be signalled until the priority drop has happened. This
can cause issues when, for example, an interrupt remains active while
a long running process takes place, such as when
irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed
When accidentally setting “kvm-arm.vgic_v4_enable=1” on a system that has
no MSI controller device tree node and GICv4, it results a panic as
“gic_domain” is NULL and the kernel attempts to access it.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
Mem abort info:
ESR = 0x0000000096000006
CPU: 1 UID: 0 PID: 295 Comm: lkvm-static Not tainted 7.1.0-rc4-ge3f15ad3970e #5 PREEMPT
Hardware name: linux,dummy-virt (DT)
pstate: 81402005 (Nzcv daif +PAN -UAO -TCO
host1x: bus: Fix missing ops null check in error teardown
In the Linux kernel, the following vulnerability has been resolved:
host1x: bus: Fix missing ops null check in error teardown
In host1x_device_init(), the error teardown paths do not check
client->ops before dereferencing it, unlike the forward init paths
which correctly guard with 'client->ops &&'. This can result in a
NULL pointer dereference if client->ops is NULL.
Fix by adding the missing client->ops check in both the teardown
and teardown_late labels.
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/gsp: add SEC2 to GA100 chip table
The booter-load and booter-unload firmware run on the SEC2 falcon.
During tu102_gsp_oneinit(), the booter constructor needs device->sec2
to access the SEC2 falcon.
Without the .sec2 entry, device->sec2 is NULL and this dereference
crashes during GSP-RM boot.
wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o netdetect
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o netdetect
Clearly, from a user perspective, it must be valid to configure
WoWLAN and then suspend while not connected to a network. Since
mac80211 doesn't distinguish these cases and simply calls the
driver to suspend whenever WoWLAN is configured, the driver has
to cleanly handle the case where it's called for WoWLAN, it's
not connected but there's also no netdetect configured.
Remove the WARN_ON() and keep returning 1 to disconnect and
then suspend.
netfilter: nf_conntrack_expect: zero at allocation time
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_expect: zero at allocation time
There are occasional LLM hints wrt. leaking uninitialized data to
userspace via ctnetlink. Just zero at allocation time,
expectations are not frequently used these days.
Intentionally keeps _init as-is because we could theoretically
support re-init, so add the missing exp->dir there.
freevxfs: don't BUG() on unknown typed-extent type
In the Linux kernel, the following vulnerability has been resolved:
freevxfs: don't BUG() on unknown typed-extent type
vxfs_bmap_typed() handles four typed-extent types and calls BUG() in
its default case, so an on-disk typed extent with any other type value
crashes the kernel. It is reachable from ioctl(FIBMAP) on a regular
file:
kernel BUG at fs/freevxfs/vxfs_bmap.c:230!
RIP: vxfs_bmap_typed fs/freevxfs/vxfs_bmap.c:230 [inline]
vxfs_bmap1+0x128a/0x12d0 fs/freevxfs/vxfs_bmap.c:257
Replace the BUG() with WARN_ON_ONCE() and return 0 -- the value
vxfs_bmap_typed() already returns on failure (and from the DEV4 case
above); vxfs_ge
crypto: ccp - Fix possible deadlock in SEV init failure path
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Fix possible deadlock in SEV init failure path
__sev_platform_init_handle_init_ex_path() calls
rmp_mark_pages_firmware() with locked=false while the parent
function of init_ex_path already acquired the sev_cmd_mutex.
In the case of an RMPUPDATE failure for any page after the first, the cleanup
path would invoke reclaim pages which would result in a deadlock in
sev_do_cmd.
Pass locked=true to honor the lock status of the parent function.
ksmbd: remove stale channels from all sessions on teardown
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: remove stale channels from all sessions on teardown
ksmbd_sessions_deregister() removes a connection's channels from other
sessions' channel lists only while conn->binding is still set:
if (conn->binding) {
hash_for_each_safe(sessions_table, ...)
ksmbd_chann_del(conn, sess);
}
conn->binding is a transient flag: it is cleared once a binding
SESSION_SETUP completes, and also by a subsequent non-binding
SESSION_SETUP on the same connection (a reauthentication on a bound
channel, or a new SessionId==0 setup). A connection that has bound a
channel into another se
Critical · CVSS 9.3EPSS 0.79%Public exploitNo fix published
ipv4: validate checksum_start before completing checksum
In the Linux kernel, the following vulnerability has been resolved:
ipv4: validate checksum_start before completing checksum
If a packet with bad checksum metadata gets into the ipv4 stack,
skb_checksum_help can corrupt the network header and cause a bunch of
mischief.
This was discovered and reported by Paulos, and has been reporoduced
by others independently since.
We really shouldn't allow such packets in, but as a defence
in depth measure, let's also check before we complete the checksum.
A more complete validation at input is forthcoming, but needs more work.
ipv4: free inet_opt and ireq_opt after an RCU grace period
In the Linux kernel, the following vulnerability has been resolved:
ipv4: free inet_opt and ireq_opt after an RCU grace period
tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the
child socket (newinet->inet_opt) without copying it.
Another cpu can concurrently process a retransmitted SYN for the same
request socket, and send a SYNACK from tcp_check_req().
tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt
under rcu_read_lock() only, and ip_build_and_send_pkt() and
ip_options_build() then read opt->optlen twice.
Note that the SYNACK timer itself is not an issue: it holds a
reference on its request socket, and