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
net/sched: sfq: clamp quantum to avoid signed overflow soft lockup
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sfq: clamp quantum to avoid signed overflow soft lockup
sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A
device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU
2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN
and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning
sfq_dequeue() under the qdisc lock.
Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The
lower bound also covers q->quantum == 0 (psched_mtu() returning 0),
which spins sfq_dequeue() identically. sfq_change() alr
net/sched: sch_teql: restore skb->dev on the slave failure path
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_teql: restore skb->dev on the slave failure path
teql_master_xmit() sets skb->dev = slave before calling the slave's
ndo_start_xmit(), but never restores it when that transmit fails. The
skb then walks on to the next slave still pointing at the previous one.
If a later slave has no resolved neighbour, teql_resolve() hands the skb
to neigh_event_send(), which queues it on that neighbour's arp_queue
with the stale skb->dev. skb->dev holds no reference, so deleting the
previous slave frees the net_device while the skb is still queued.
Whatever runs next on that
In the Linux kernel, the following vulnerability has been resolved:
tpm: st33zp24: Return zero on status read failure
st33zp24_status() ignores the result of the transport read and returns
data even when no byte was received. The I2C transport, for example,
skips i2c_master_recv() when the register-select write is short or fails,
leaving data uninitialized. The resulting stack value can be interpreted
as TPM_STS flags and let status checks complete spuriously.
The status callback cannot propagate a transport error. Return zero
unless recv() reports exactly one byte. With no status bits set, callers
retry or take their existing timeout or e
crypto: acomp - allocate async request context when cloning
In the Linux kernel, the following vulnerability has been resolved:
crypto: acomp - allocate async request context when cloning
ACOMP_REQUEST_ON_STACK() reserves only enough storage for the
synchronous fallback. When an async implementation is selected, callers
clone that stack request before retrying, but acomp_request_clone()
currently copies only the stack-sized object. The clone therefore has no
storage for the async provider request context, and providers such as QAT
write past the allocation through acomp_request_ctx(). KASAN does report
a slab OOB write.
Allocate a zeroed clone large enough for the runtime acomp request size,
copy o
ASoC: dapm: Fix off-by-one check on the second enum channel
In the Linux kernel, the following vulnerability has been resolved:
ASoC: dapm: Fix off-by-one check on the second enum channel
The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches
e->items, but it lets item[1] be equal to it. Both go on to
snd_soc_enum_item_to_val(), which indexes e->values with no bound of
its own, so an enum with a value table reads one element past the end.
The indexing arrived with the MUX consolidation, which relaxed the
item[1] check in the same hunk. The value MUX handler it deleted used
>= there, and the snd_soc_put_enum_double() in soc-ops.c still does.
Only adav80x pairs a value table with two s
In the Linux kernel, the following vulnerability has been resolved:
libceph: validate banner payload length
When parsing the Ceph messenger v2 protocol banner, the `payload_len` field
is decoded from the banner prefix. If a client sends a banner with a
`payload_len` of 0, the kernel sets up a 0-length socket read. This
violates an invariant in the state machine, triggering a warning in
`populate_in_iter()`:
------------[ cut here ]------------
!iov_iter_count(&con->v2.in_iter)
WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter
net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070
WARNING: net/ceph/messenger_v2.c:3129 at cep
samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify
In the Linux kernel, the following vulnerability has been resolved:
samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify
ftrace_direct_multi_init() assigns kthread_run()'s return value to
simple_tsk without an IS_ERR() check. When kthread_run() fails it
returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads
with simple_tsk holding an error pointer. On unload,
ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(),
leading to a null-pointer-dereference.
Check the return value of kthread_run() with IS_ERR(); on failure,
unregister the ftrace direct call and propagate the error code.
net/smc: release the internal TCP sock on IPPROTO_SMC socket creation failure
In the Linux kernel, the following vulnerability has been resolved:
net/smc: release the internal TCP sock on IPPROTO_SMC socket creation failure
IPPROTO_SMC sockets create an internal TCP sock ("clcsock") from the
proto->init hook. When socket creation fails after proto->init has
run - e.g. a cgroup BPF program attached to BPF_CGROUP_INET_SOCK_CREATE
denies the socket - sk_common_release() only invokes sk_prot->destroy
if it is set, but neither smc_inet_prot nor smc_inet6_prot defines it,
and smc_destruct() returns early unless sk_state is SMC_CLOSED. As a
result, every failing socket(AF_INET, SOCK_STREAM, IPPROTO_SMC) call
leaks one tcp_s
drm/xe: Reject page faults from non-fault-mode scratch VMs
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Reject page faults from non-fault-mode scratch VMs
Having scratch enabled does not make a VM capable of handling recoverable
page faults. Allowing scratch VMs through the ASID lookup also admits
dma-fence mode VMs.
If such a VM faults on an already valid VMA, the handler reports success
without fixing the fault, causing the GPU to retry indefinitely.
Only allow fault-mode VMs through the ASID lookup. Fault-mode VMs using
scratch remain supported, while faults from 3D VMs are rejected.
(cherry picked from commit bfb24a06405b652d37831f3fb66b71d33a6605de)
virtio-net: Ensure that TCP packets don't overflow gso_segs
In the Linux kernel, the following vulnerability has been resolved:
virtio-net: Ensure that TCP packets don't overflow gso_segs
The user can specify any gso_size in a packet crafted with an AF_PACKET
PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the
same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user
crafts a packet with gso_size < 8, there is a risk for partial GSO to
overflow the 16-bit gso_segs field when dividing the SKB length by
gso_size.
Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep
gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly
tested at tools/tes
netfilter: nf_tables: move hardware offload step after building the chain blob
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: move hardware offload step after building the chain blob
Allocate the chain blob before the ruleset offload to reduce chances of
entering an inconsistent state where the offloaded ruleset in the nic
and the software ruleset differ.
netfilter: nf_tables: skip double clone set expressions on element insert
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: skip double clone set expressions on element insert
Both the dynset and newsetelem path clone the existing set expressions
when setting set element expressions if no override expressions are
provided. This results in a double clone, once to clone the template set
expressions then another clone on the new element. Add a flag to
annotate if userspace provides a override expression (ie. expression of
the same type of the set but different configuration), otherwise borrow
the existing expression from the set. Add conditionals to release
expression iif they
ALSA: control: Don't add invalid kcontrols to LED layer
In the Linux kernel, the following vulnerability has been resolved:
ALSA: control: Don't add invalid kcontrols to LED layer
The kcontrol LED state layer tries to track the all associated
kcontrol elements with naive assumptions that they are readable.
But one can create a write-only element that has no get callback (even
a user element can do it), and this may lead to a NULL dereference at
the call chain of snd_ctl_led_notify(), as found by syzkaller.
For avoiding the Oops, add a sanity check of the kcontrol's info and
get callbacks, and just skip the invalid kcontrols before assigning
the kctl to the LED layer.
net: stmmac: restore NET_IP_ALIGN in the RX DMA offset
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: restore NET_IP_ALIGN in the RX DMA offset
Since the RX path was converted to zero-copy, the page pool page is handed
to the stack directly as the skb head, and the offset the DMA engine writes
at is what determines the alignment of the packet headers.
Before the conversion the payload was copied into an skb obtained from
napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The
conversion moved the headroom into stmmac_rx_offset() but did not carry
over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP
header now lands misaligned:
64 (