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
KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails
Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the
nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and
vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could
re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page.
Note, both SVM and VMX (as of commit 11722439fb20 ("KVM: nVMX: Ensure
KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit") ensure the request
is cleared on VM-Exit (including the "forced" case), i.e. there is no risk
In the Linux kernel, the following vulnerability has been resolved:
audit: fix exe mark UAF in kill_rules()
kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit
tree is pruned. It drops entry->rule.exe before removing the rule from
the RCU-visible filter lists.
After a rule has been installed with AUDIT_ADD_RULE, which requires
CAP_AUDIT_CONTROL, removing the watched directory can race with another
task that is still evaluating the rule. In that case, fsnotify can free
the executable mark before the reader reaches audit_mark_compare(),
causing a use-after-free.
KASAN reports:
BUG: KASAN: slab-use-after-free in audit
Media · CVSS 5.4EPSS 0,16%Sin corrección publicada
HID: multitouch: stop the release timer from being rearmed on remove
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: stop the release timer from being rearmed on remove
mt_remove() quiesces the sticky-finger timer before stopping the
hardware:
timer_delete_sync(&td->release_timer);
sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group);
hid_hw_stop(hdev);
timer_delete_sync() waits for a running callback and dequeues the timer,
but it does not stop the timer from being armed again. The transport is
still delivering reports at that point, and the report path rearms it:
if (app->quirks & MT_QUIRK_STICKY_FINGERS) {
if (td->mt_io_flags & MT_IO_SLO
Media · CVSS 6.8EPSS 0,16%Sin corrección publicada
ipvs: bound LBLCR and LBLC cache growth
In the Linux kernel, the following vulnerability has been resolved:
ipvs: bound LBLCR and LBLC cache growth
ip_vs_lblcr_new() and ip_vs_lblc_new() create cache entries for
every previously unseen destination address. The table max_size only
tells the periodic collector to reclaim entries after the cache has
already exceeded the limit. It does not reclaim entries that the
attacker continues to use.
Reject new cache entries once either table reaches max_size * 3 / 2.
The extra headroom lets the periodic collector catch up while the
existing scheduler fallback continues to use the selected destination
when cache creation fails. New traffic th