NFSv4/pnfs: key the data server cache on the NFS version
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pnfs: key the data server cache on the NFS version
nfs4_pnfs_ds_add() keys the per-net data server cache on the multipath
address set alone, and struct nfs4_pnfs_ds records no version. That
suffices for the files layout driver, which always connects with version
4, but flexfiles takes its version tuple from GETDEVICEINFO per device,
and one address can legitimately serve both NFSv3 and NFSv4.
Two deviceids on one address with different ds_versions[0].version
therefore share a single nfs4_pnfs_ds, and whichever mirror connects
first pins ds_clp to its own version. The
bnxt_en: Fix call to hardware monitoring event handler
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix call to hardware monitoring event handler
The first parameter of hwmon_notify_event() is supposed to be the hardware
monitoring device. The bnxt driver calls it with the platform device as
first parameter instead. This API break results in undefined behavior and
may result in a crash.
Pass the hardware monitoring device as parameter instead to fix the
problem.
net/sched: account classifier filter allocations to memcg
In the Linux kernel, the following vulnerability has been resolved:
net/sched: account classifier filter allocations to memcg
Allocations in the tc classifier *_change() paths (filter objects,
per-CPU counters, and per-filter aux data) use plain GFP_KERNEL without
__GFP_ACCOUNT, allowing unprivileged users to pin kernel memory outside
memcg charging. The shared tcf_exts_init_ex() action array allocation in
cls_api.c was also uncharged; this patch closes it along with the
per-classifier filter-object/percpu/aux allocations that remain
unaccounted.
Add GFP_KERNEL_ACCOUNT to:
- the shared tcf_exts_init_ex() action array (cls_api.c), common to
net: sparx5: fix sleep in atomic context in MAC table access
In the Linux kernel, the following vulnerability has been resolved:
net: sparx5: fix sleep in atomic context in MAC table access
sparx5_set_rx_mode() runs with netif_addr_lock_bh held and iterates
dev->mc via __dev_mc_sync(), which per address calls sparx5_mc_sync() /
sparx5_mc_unsync() -> sparx5_mact_learn() / sparx5_mact_forget(). These
take sparx5->lock, a mutex, and then poll the MAC access command
register with readx_poll_timeout(). A mutex may block, which is not
allowed from atomic context.
Convert the driver to the new .ndo_set_rx_mode_async callback introduced
in commit 3554b4345d85 ("net: introduce ndo_set_rx_mode_async and
netd
In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition
The VMBus module initialization function, hv_acpi_init(), currently
does nothing when running in the root partition and root is not nested
in another VM. But the initialization function reports success, so the
VMBus module is indeed loaded. VMBus functionality is not actually
needed, but the VMBus module must be loaded so that hv_vmbus_exists()
can answer correctly. Furthermore, the mshv_root dependency on the
VMBus module is needed as described in the commit message for
840b740a35bf ("mshv: Add con
In the Linux kernel, the following vulnerability has been resolved:
fuse: Fix the condition to enable over-io-uring
The existing condition in fuse_uring_cmd() is there only to avoid
disabling io-uring for connections that already run with it, missing
was a condition to refuse any IORING_OP_URING_CMD if the
connection/channel didn't get enabled because of missing FUSE_INIT
reply flag FUSE_OVER_IO_URING. Without the reply flag the barrier in
fuse_uring_ready() doesn't work and IO could already be going on and
cause deadlock states (at a minimum one between fch->bg_lock and
queue->lock).
The change itself is trivial, but brings behavior chang
arm64: process: Fix context switching MTE store-only tag check
In the Linux kernel, the following vulnerability has been resolved:
arm64: process: Fix context switching MTE store-only tag check
SCTLR_EL1.TCSO0 is set when user opt-in for MTE store-only tag check
mode. However, it is not part of SCTLR_USER_MASK which imply that on
context switch we never clear SCTLR_EL1.TCSO0, so we are leaking that
setting into another task.
Fix that by including SCTLR_EL1_TCSO0_MASK into SCTLR_USER_MASK
Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path
btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size
of 256 bytes, but hands the host controller the SKB buffer as is:
err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data,
round_up(skb->len, MTK_SDIO_BLOCK_SIZE));
Only skb->len bytes hold packet data, so the controller reads up to 255
bytes of uninitialised memory and sends it to the device over the SDIO
bus. Depending on how much tailroom slack the SKB allocation happens to
carry, that read can also extend past the end of the bu
Bluetooth: btnxpuart: Validate the FW dump header length
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btnxpuart: Validate the FW dump header length
nxp_process_fw_dump() pulls the ACL header off the frame and then reads
seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data,
without checking that the ACL payload is long enough to contain it.
h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the
number of payload bytes named in that header, so skb->len is 4 + dlen
with dlen supplied by the controller and possibly smaller than the 8
byte dump header, or zero. A short frame with connection handle 0xfff
therefore reads both fields fr
Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop
rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter
Negotiation) frame without checking for zero. When the remote peer
sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg
path to enter an infinite loop when fragmenting data, as each fragment
has size == min_t(size_t, len, 0) == 0, so the remaining length never
decreases. The infinite allocation of zero-length skbs exhausts all
system memory.
Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated
value is ze
Bluetooth: do not leak an hci_conn when a second LE connect is rejected
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: do not leak an hci_conn when a second LE connect is rejected
create_le_conn_complete() decides whether the failed connection is
still pending by comparing it against hci_lookup_le_connect(), which
returns the first LE connection in BT_CONNECT. That is the same
connection only while at most one is pending.
Two can be pending. Connections created on the passive scan path sit
in BT_CONNECT with HCI_CONN_SCANNING set and are invisible to
hci_lookup_le_connect() until hci_le_create_conn_sync() clears the
flag when their command is issued, so the -EBUSY guard in
hci_c
In the Linux kernel, the following vulnerability has been resolved:
xsk: honor XDP_TX_METADATA in zero-copy path
The zero-copy path reads TX metadata whenever the UMEM has metadata space,
even if the descriptor does not set XDP_TX_METADATA. Pass descriptor
options through the metadata helpers and ignore metadata unless the option
is set.
This does not fix the existing per-WQE metadata handling for mlx5 MPWQEs.
Only the descriptor that starts a session passes through
xsk_tx_metadata_request() and configures offload state shared by the batch.
Metadata on descriptors joining an open session is therefore not validated
and does not configure it
octeontx2-af: fix NULL deref in NIX TM tree debugfs read path
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: fix NULL deref in NIX TM tree debugfs read path
rvu_dbg_nix_tm_tree_display() dereferences pfvf->sq_ctx without
checking whether the SQ context has been allocated. Reading
/sys/kernel/debug/octeontx2/nix/tm_tree for a NIX LF whose transmit
queues are not set up triggers a kernel oops.
Guard the read path the same way rvu_dbg_nix_tm_tree_write() already
does and return -EINVAL with a seq_file message when sq_ctx is NULL.
octeontx2-vf: fix workqueue and netdev race in probe/remove
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-vf: fix workqueue and netdev race in probe/remove
Initialize the VF workqueue before register_netdev() so ndo_set_rx_mode
does not queue work on a NULL workqueue. Unregister the netdev before
destroying the workqueue, and add proper probe error cleanup.
net/sched: act_ife: Only operate on Ethernet frames
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ife: Only operate on Ethernet frames
act_ife encapsulates/decapsulates the original Ethernet header and uses
skb->dev->hard_header_len as the length of that header. That is only
correct for Ethernet devices: on a device where hard_header_len does not
match the L2 header that was actually pulled (PPP reports PPP_HDRLEN
while nothing is stripped on ingress), the ingress skb_push()/skb_pull()
use the wrong length and can hit skb_under_panic when headroom is tight.
IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites
h_source/h_dest/h_proto, and
net: mana: Cap MSI-X vectors to the device MSI-X table size
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Cap MSI-X vectors to the device MSI-X table size
mana_gd_query_max_resources() sizes gc->num_msix_usable from resp.max_msix
and the CPU count, but never from the device MSI-X table. On a 1792 vCPU
M-series VM that yields 1793 while the table has 1024 entries, and
mana_gd_setup_remaining_irqs() then walks indices 1..1792, running off the
end of the region mapped by msix_map_region():
BUG: unable to handle page fault for address: ff8e347f8b99800c
RIP: 0010:msix_prepare_msi_desc+0x7a/0x90
RAX: 0000000000004000 RBX: ff4330cb164ea780 RCX: ff8e347f8b998000
Cal
net/rds: use wq_has_sleeper() in rds_cong_map_updated()
In the Linux kernel, the following vulnerability has been resolved:
net/rds: use wq_has_sleeper() in rds_cong_map_updated()
rds_cong_map_updated() runs after a peer's congestion map has been
rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the
clear-all in the loopback and IB send-completion paths). It bumps
rds_cong_generation and then checks waitqueue_active() on
map->m_waitq and on rds_poll_waitq to decide whether anyone needs
waking. atomic_inc() carries no ordering and waitqueue_active() is a
plain load, so nothing orders the map and generation stores before
the wait queue reads. The waiters do the mirror image: rds_cong
octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: fix NULL deref of af_xdp_zc_qidx on rep setup
af_xdp_zc_qidx tracks receive queues using AF_XDP zero-copy and is
allocated during PF/VF probe. Representors and other non-AF_XDP paths
leave the pointer NULL, but several call sites used test_bit() on it
unconditionally.
Switching to devlink eswitch mode creates representors and runs
otx2_init_hw_resources(), which reaches otx2_pool_aq_init() and oopses
when dereferencing the NULL bitmap. Add NULL checks before every
af_xdp_zc_qidx test_bit() use in the RSS, ethtool, XSK, and pool init
paths.
octeontx2-af: fix cn20k mailbox lifetime on repeated rvu_mbox_init()
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: fix cn20k mailbox lifetime on repeated rvu_mbox_init()
rvu_mbox_init() is called separately for AF-PF mailboxes during probe
and for AF-VF mailboxes when SR-IOV is enabled. Each call used to
allocate a new ng_rvu object, leaking the first allocation when the
pointer was overwritten on the second call.
Sharing one ng_rvu across both paths exposed several teardown bugs:
the error path freed all cn20k mailbox DMA and kfree()d ng_rvu even
when only the failing init type should be unwound, leaving live AF-PF
mailbox memory in use after an AF-VF init failure. mut
net/sched: act_skbmod: fix length calculations and avoid invalid header warnings
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_skbmod: fix length calculations and avoid invalid header warnings
syzbot reported a warning in skb_network_header_len() triggered
by tcf_skbmod_act():
!skb_transport_header_was_set(skb)
WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline]
WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55
There are a few issues in tcf_skbmod_act():
1. Calling skb_network_header_len() assumes skb->transport_header is set,
which is not guarante