In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: fix LE list UAF on reset
hci_cc_reset() clears the LE accept and resolving lists without taking
hdev->lock. Other command-complete handlers serialize updates to these
lists with that lock, and the debugfs readers hold it while walking them.
This permits the reset completion and a debugfs read to interleave as
follows:
hci_rx_work debugfs reader
----------- --------------
lock hdev->lock
fetch current entry
list_del(entry)
kfree(entry)
Bluetooth: hci_event: validate LE Set CIG Parameters response
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: validate LE Set CIG Parameters response
The Command Complete dispatch validates only the fixed part of the LE Set
CIG Parameters response. After that part is pulled from the skb,
hci_cc_le_set_cig_params() trusts num_handles and reads each entry in the
trailing handle array.
Matching num_handles against the command's num_cis does not guarantee
that the response contains the advertised handles. A truncated response
from a malfunctioning controller can therefore make the handler read
beyond the skb data.
Validate that the remaining skb data contains al
Bluetooth: hci_sync: Fix accept list UAF during suspend
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: Fix accept list UAF during suspend
hci_update_event_filter_sync() walks hdev->accept_list while sending a
synchronous HCI command for each remote-wakeup device. The suspend path
holds hdev->req_lock, but accept-list updates are serialized by hdev->lock.
Consequently, remove_device() can free the current list entry during the
controller wait.
The following interleaving causes the use-after-free:
hci_update_event_filter_sync() remove_device()
fetch accept-list entry
hci_set_event_filter_sync()
wait for controller response hci_dev_lock()
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_aml: validate firmware segment lengths
aml_download_firmware() reads two lengths from the firmware header and
uses them to build pointers before checking that the header and segment
data are present. A truncated or inconsistent firmware image can make
the driver read past firmware->data while constructing TCI commands.
Reject images shorter than the header and ensure that the ICCM and DCCM
ranges fit within the loaded firmware before downloading either segment.
selinux: reject a class permission count below its inherited common
In the Linux kernel, the following vulnerability has been resolved:
selinux: reject a class permission count below its inherited common
security_get_permissions() maps an inherited common's permissions into
an array sized by the class's own permissions.nprim, but class_read()
takes that nprim verbatim from the policy image and never checks that it
covers the common. A class that inherits a common of N permissions while
declaring a smaller nprim is accepted, and on load the common's
permissions are written past the class-sized array -- an out-of-bounds
heap write.
Reject a class whose permission count is below its inherited common's.
Well-
selinux: do not cancel a policy conversion that never started
In the Linux kernel, the following vulnerability has been resolved:
selinux: do not cancel a policy conversion that never started
sel_write_load() calls selinux_policy_cancel() when sel_make_policy_nodes()
fails, and that helper dereferences the outgoing policy to cancel its
sidtab conversion. On the first policy load there is no outgoing policy:
security_load_policy() returns early for that case, before it converts
anything, and state->policy is still NULL. A first load that fails while
building the selinuxfs tree therefore takes a NULL dereference in
selinux_policy_cancel(), reached from a write(2) to /sys/fs/selinux/load.
Skip the cance
selinux: reject a permission value exceeding the class permission count
In the Linux kernel, the following vulnerability has been resolved:
selinux: reject a permission value exceeding the class permission count
perm_read() bounds a permission value by SEL_VEC_MAX but never by the
nprim of the owning class or common, which is taken verbatim from the
policy image. security_get_permissions() then writes perms[value - 1]
into an nprim-sized kcalloc() array, so a class declaring fewer
permissions than its largest permission value drives an out-of-bounds
heap write. The top-level symbol tables are validated this way; the
nested per-class permission table is not.
Reject a permission whose value exceeds nprim, whic
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix F55 transmitter electrode count typo
During F55 sensor detection, the transmitter (TX) electrode count was
incorrectly assigned the value of the receiver (RX) electrode count
due to copy-paste typos.
This incorrect value was then propagated to the driver data and used
by F54 to determine the diagnostics report size. On devices with more
RX than TX electrodes, this inflated the perceived TX count, leading
to incorrect report size calculations and potential out-of-bounds
buffer accesses.
Fix the typos by correctly assigning the TX electrode count
In the Linux kernel, the following vulnerability has been resolved:
Input: psxpad-spi - set driver data before use
psxpad_spi_suspend() retrieves the controller state with
spi_get_drvdata(), but probe never stores it, so suspend dereferences a
NULL pointer. Store it during probe.
In the Linux kernel, the following vulnerability has been resolved:
drm/connector/hdmi: Fix out of bounds memory read
A helper function was copying a given audio infoframe into the
connector's copy but using the size of the destination (a generic
target, sized to accept many different data blocks) not the source (a
very specific type of data block). Thus, it was copying 60 bytes of
data from a 28 byte allocation.
Fix that by using the source size instead, together with a build bug
on the source size actually being smaller than the destination.
I hit this running KUnit tests under KASAN (while debugging something
else entirely). In the rea
netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort path
In nft_flow_rule_offload_abort(), WARN_ON_ONCE(err) is triggered on every
error during rollback, including -ENOMEM. Memory allocation failures are
expected under low-memory conditions and do not indicate a kernel bug.
Trace for example:
nft_flow_offload_chain() // FLOW_BLOCK_BIND
nft_flow_block_chain()
nft_chain_offload_cmd()
nft_block_offload_cmd()
->ndo_setup_tc()
nsim_setup_tc()
flow_block_cb_setup_simple()
flow_block_cb_alloc() // fails to -ENO
ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers
In the Linux kernel, the following vulnerability has been resolved:
ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers
The irq handlers take a struct device pointer and call
dev_get_drvdata() to obtain the driver data. However, the driver
data is only set at the end of probe, after devm_request_irq(),
so an interrupt taken in between causes the handlers to pass a
NULL pointer to readl() and crash.
Pass the private data directly as the devm_request_irq() argument
instead of the device pointer, matching what the handlers expect.
af_packet: Don't send zero-byte data in tpacket_snd().
In the Linux kernel, the following vulnerability has been resolved:
af_packet: Don't send zero-byte data in tpacket_snd().
syzbot reported a WARNING in __dev_queue_xmit() triggered via tpacket_snd():
skb_assert_len
WARNING: at include/linux/skbuff.h:2753 skb_assert_len
WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781
Call Trace:
<TASK>
dev_queue_xmit include/linux/netdevice.h:3448 [inline]
packet_xmit+0x243/0x310 net/packet/af_packet.c:276
tpacket_snd net/packet/af_packet.c:2907 [inline]
packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134
When sending 0-byte packets via TPACKET ring buffer on devices with no
hard
net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock
In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is
deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring
ESW devcom lock without condition. In addition, in case of peer_flow,
__mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock.
This results in an AA deadlock.
To fix this, introduce a new PEER flag that is set on flows created as
peer flows (the duplicate flows on peer devices), and check it in
mlx5e_tc_del_flow() before acquiring ESW devcom lock.
Lockdep splat:
In the Linux kernel, the following vulnerability has been resolved:
serial: amba-pl011: synchronize DMA teardown
dmaengine_terminate_all() does not wait for a running callback, so the TX
callback can still touch the TX buffer after it is freed. The RX poll
timer reads the RX buffers without the port lock.
Switch to dmaengine_terminate_sync() and delete the RX timer before
freeing the buffers.
thunderbolt: Fix bandwidth group reservation indexing
In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix bandwidth group reservation indexing
Valid bandwidth group IDs range from 1 through MAX_GROUPS, while Group
ID 0 is reserved. tb_consumed_dp_bandwidth() uses the Group ID directly
to index its local group_reserved[] array.
The array currently has MAX_GROUPS entries, so its valid indices are 0
through MAX_GROUPS - 1. Group ID MAX_GROUPS therefore accesses one
element past the end, and the final group's reserved bandwidth is not
included when the array is summed.
Give group_reserved[] MAX_GROUPS + 1 entries so direct Group ID
indexing covers the reserved ID
In the Linux kernel, the following vulnerability has been resolved:
net: remove WARN_ON_ONCE() from sk_mc_loop()
sk_mc_loop() can be called for sockets that are neither AF_INET
nor AF_INET6 (e.g. AF_PACKET sockets when sending packets via raw/packet
socket over virtual devices such as VRF or ipvlan).
In such cases, sk_family is not AF_INET/AF_INET6 and sk_mc_loop() falls
through the switch statement and triggers WARN_ON_ONCE(1).
Non-INET sockets do not support IP_MULTICAST_LOOP or IPV6_MULTICAST_LOOP
options, so loopback should default to true without generating a warning.
In the Linux kernel, the following vulnerability has been resolved:
ata: pata_sl82c105: fix bridge revision use-after-free
pci_get_slot() returns a referenced PCI device. Commit 44c10138fd4b
("PCI: Change all drivers to use pci_device->revision") replaced a
configuration-space read with direct access to the cached revision field,
but left that access after pci_dev_put(). The bridge may therefore be freed
before its revision is read.
Read the revision before dropping the reference.
net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header
In the Linux kernel, the following vulnerability has been resolved:
net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header
dev_validate_header() reads dev->hard_header_len directly when
zero-padding short link layer headers for CAP_SYS_RAWIO holders:
if (capable(CAP_SYS_RAWIO)) {
memset(ll_header + len, 0, dev->hard_header_len - len);
return true;
}
Packet send paths call dev_validate_header() on skbs whose headroom was
allocated from an earlier hard_header_len read. If the device is
reconfigured so that dev->hard_header_len increases before validation,
the memset writes past the reserved buffer, an out-of-b