In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
New sk should not be added to parent socket accept queue after last
l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and
state set to BT_CLOSED, as that can result to UAF on dereferencing the
dangling parent reference.
l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown,
due to chan->state accessed without consistent locking:
[Task 1] [Task 2]
l2cap_sock_release(parent) l2cap_connect
l2cap_sock_shutdown pchan = l2cap_global
Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan
For L2CAP sockets without owning sk->sk_socket, reading
l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() ->
l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks,
but access in l2cap_sock_cleanup_listen() has unsafe lockless read.
[Task 1] [Task 2 (hdev->workqueue)]
l2cap_sock_release(parent) l2cap_disconn_cfm
l2cap_sock_cleanup_listen l2cap_conn_del
bt_accept_dequeue l2cap_chan_del
lock_sock(sk)
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
net: fix a resource leak in copy_net_ns() error handling path
In the Linux kernel, the following vulnerability has been resolved:
net: fix a resource leak in copy_net_ns() error handling path
Currently, preinit_net() does two things:
(1) call ns_common_init() which might fail
(2) initialize resources which does not fail
However, preinit_net() is returning early when (1) fails, and copy_net_ns()
is jumping to the dec_ucounts: label. As a result, resources allocated by
net_alloc() are leaking. We need to call key_remove_domain() and
net_passive_dec() in order to release resources allocated by net_alloc().
We cannot simply jump to the put_userns: label when preinit_net() failed,
for (2) is not yet
net/sched: fq: add overflow bounds to quantum and initial quantum
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq: add overflow bounds to quantum and initial quantum
fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 *
psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy
with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return
0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit
arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill
loop adds 0 to f->credit (which stays <= 0) and goto begin loops
forever under the qdisc lock, creating a soft lockup.
Clamp psched_mtu() to [1, 1 << 20] before
net/sched: fq_codel: clamp default quantum and mtu
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq_codel: clamp default quantum and mtu
fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without
clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0
accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which
overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(),
causing an infinite loop and soft lockup. Emulate fq_codel_change()
and constrain to [256, FQ_CODEL_QUANTUM_MAX].
The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit
below, and fq_codel_change() never updates it. codel_should_drop()
tests
net/sched: fq_pie: clamp default quantum to avoid signed overflow
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq_pie: clamp default quantum to avoid signed overflow
fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without
clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0
accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which
overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(),
causing an infinite loop and soft lockup. Emulate fq_pie_policy which
is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20].
256 matches fq_codel's floor and is a sane minimum for a DRR quantum.
Conditions to recreate th
net/sched: hhf: clamp quantum before hhf_change() to avoid overflow
In the Linux kernel, the following vulnerability has been resolved:
net/sched: hhf: clamp quantum before hhf_change() to avoid overflow
hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow
check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting
MTU 2147483634) makes weight * quantum overflow the signed deficit in
hhf_dequeue(), spinning forever.
Clamp q->quantum before hhf_change() so both the opt and !opt paths see
a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with
a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option
present) fails with -EINVAL because hhf_change() re