flow_dissector: avoid u16 truncation of skb->len when computing thoff
In the Linux kernel, the following vulnerability has been resolved:
flow_dissector: avoid u16 truncation of skb->len when computing thoff
__skb_flow_dissect() computes key_control->thoff using:
key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen);
min_t(u16, ...) casts both arguments to u16 before comparing them.
Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the
truncated length wins and thoff is set to a bogus small value, even
when the dissection succeeded. For example, an IPv4/TCP frame with
skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as
skb_probe_transport_header() point the transpor
net: always dissect GSO packets in __virtio_net_hdr_to_skb()
In the Linux kernel, the following vulnerability has been resolved:
net: always dissect GSO packets in __virtio_net_hdr_to_skb()
Commit 9e8db5913264 ("net: avoid false positives in untrusted gso
validation") added a '&& skb->network_header' check before flow-dissecting
GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM in
__virtio_net_hdr_to_skb(), because some callers (such as tun_get_user(),
tun_xdp_one(), virtnet_receive_done(), and raw_verify_header()) called
virtio_net_hdr_*_to_skb() before initializing skb->network_header and
skb->dev.
Because __alloc_skb() and __build_skb_around() zero-initialize
skb->network_header to 0 (unlike mac_he
devlink: fix devlink_rel reference leak when notify work is pending
In the Linux kernel, the following vulnerability has been resolved:
devlink: fix devlink_rel reference leak when notify work is pending
devlink_rel_nested_in_notify_work_schedule() takes a reference on the
devlink_rel for the notify work and then queues the work, ignoring the
return value of schedule_delayed_work(). If the work is already pending,
nothing new is queued, the work runs only once and drops only one
reference, so the extra one is leaked together with the devlink_rel and
its index in devlink_rels.
This is easy to hit. devl_register() of a nested instance queues the
work, and if the instance is unregistered before the work has r
pfcp: make sure the SEID is linear before reading it
In the Linux kernel, the following vulnerability has been resolved:
pfcp: make sure the SEID is linear before reading it
pfcp_encap_recv() only makes sure that the UDP header and the 4 byte
PFCP header are in the linear area. When the S flag is set,
pfcp_session_recv() then reads the 8 byte SEID that follows, which is
not covered by the pskb_may_pull() check.
A short PFCP packet with the S flag set, or one whose session header
lies in a fragment, therefore makes pfcp_session_recv() read beyond the
end of the packet data, and whatever it finds there is stored in the
tunnel metadata that flower later classifies on.
Pull up to the end of the
riscv: ptrace: Zero-initialize regset buffers before copyin
In the Linux kernel, the following vulnerability has been resolved:
riscv: ptrace: Zero-initialize regset buffers before copyin
user_regset_copyin() only copies `count` bytes, so a PTRACE_SETREGSET
request with a short iov_len leaves the rest of the stack buffer
uninitialized. In riscv_vr_set() that garbage is validated and copied
into the target's vstate, and in riscv_cfi_set() it can be stored as
the target's shadow stack pointer. Zero both buffers, as the get path
already does.
flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()
In the Linux kernel, the following vulnerability has been resolved:
flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()
bpf_flow_dissect() sanitizes the offsets returned by the BPF program
with clamp_t(u16, ..., hlen).
If hlen is bigger than 65535, the upper bound is truncated before
the comparison. For instance, with hlen == 65536, both nhoff and
thoff are forced to zero, even if the program returned sane values.
This is the same class of bug as the one fixed in commit 99bda1ecbd56
("flow_dissector: avoid u16 truncation of skb->len when computing
thoff"). That fix does not cover the BPF path, because
__skb_flow_dissect() r
drm/imagination: Fix reference and vm_bo handling in remap()
In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Fix reference and vm_bo handling in remap()
When a map overlaps part of an existing mapping, pvr_vm_gpuva_remap()
splits the mapping into prev/next parts covering what the request did
not take, instead of creating something new. It gets two things wrong.
- A GEM reference is taken for each part but it's never needed and never
dropped, so it leaks one reference per split (remap-next-in-2m in
tests/imagination/pvr_vm_map.c):
CRITICAL: 33558528 bytes of shmem still held after close
- The parts still belong to the original object being split, but
p
mlxsw: spectrum_flower: Fix port range register leak in tmplt_create()
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_flower: Fix port range register leak in tmplt_create()
mlxsw_sp_flower_tmplt_create() parses a flow_cls_offload template
into a stack-local struct mlxsw_sp_acl_rule_info purely to compute
rulei.values.elusage. Parsing can acquire port range registers via
mlxsw_sp_flower_parse_ports_range(), but since this rulei never goes
through mlxsw_sp_acl_rulei_destroy(), those registers were never
released, including through chain template deletion.
Factor out of mlxsw_sp_acl_rulei_destroy() the code to actually
release the necessary resources and call from
mlxsw_sp_fl
vsock: Fix memory leak in vmci_transport_recv_dgram_cb()
In the Linux kernel, the following vulnerability has been resolved:
vsock: Fix memory leak in vmci_transport_recv_dgram_cb()
During the closure of a datagram socket, the vmci_transport_recv_dgram_cb()
function may be called, which will add the packets
to the socket's backlog; then, after the receive queue is cleared,
the __release_sock() function will move the packet back from the socket's
backlog to the receive queue, which will lead to a memory leak.
sock_close
__sock_release
__vsock_release
// take ownership by user-space
lock_sock_nested
sock_set_flag(sk, SOCK_DEAD)
vmci_transport_release
drm/vc4: Disable the V3D interrupt across runtime suspend
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Disable the V3D interrupt across runtime suspend
vc4_irq_disable() masks the V3D interrupt sources and then calls
synchronize_irq() before the V3D is powered down. However, by itself,
this is not enough to quiesce the interrupt handler.
synchronize_irq() waits for handlers that have already set
IRQD_IRQ_INPROGRESS, and for irqchips reporting IRQCHIP_STATE_ACTIVE.
A GIC interrupt chip is able to mark an interrupt active as soon as a
CPU acknowledges it, so there these checks cover the whole dispatch path.
On RPi 0-3, however, the interrupt controller is ARMCTRL, wh
ext4: don't enable large folios on encrypted inodes
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't enable large folios on encrypted inodes
Commit 709f0f1f1bf5 ("ext4: add checks for large folio
incompatibilities when BS > PS") disables large folios at mount time
if the "encrypt" feature is set. However, enabling that feature on a
mounted filesystem circumvents that check, and writing encrypted data
results in a crash:
BUG: kernel NULL pointer dereference, address: 0000000000000028
Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work
RIP: 0010:ext4_finish_bio+0xf7/0x3e0
Call Trace:
ext4_release_io_end+0x51/0x110
ext4_end_io_end+0x4c/0xe0
ext4_
rust: irq: pass RegistrationInner as cookie to request_irq
In the Linux kernel, the following vulnerability has been resolved:
rust: irq: pass RegistrationInner as cookie to request_irq
With commit ba268514ea14 ("rust: devres: fix race condition due to
nesting"), Devres::new() returns Result<Self> by value instead of
initializing in-place via PinInit. Because request_irq() is called
inside Devres::new(), registration.inner is still uninitialized when the
IRQ is enabled, so accessing registration.inner.device() in the IRQ
callback can read uninitialized memory.
Fix this by storing the Device and handler pointer in RegistrationInner
and passing RegistrationInner as the IRQ cookie after its fields ar
In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: reject short monitor TX frames
In monitor mode, lbs_hard_start_xmit() casts skb->data to a
radiotap TX header, skips that header, and then copies the 802.11
destination address from offset 4 in the remaining frame. The
generic length check only rejects zero-length and oversized skbs, so
a short monitor frame can be read past the end of the skb data.
Require enough bytes for the radiotap TX header and the destination
address field before using the monitor-mode header layout.
Crítica · CVSS 9.3EPSS 0,79%Código de explotación públicoSin corrección publicada
ipv4: validate checksum_start before completing checksum
In the Linux kernel, the following vulnerability has been resolved:
ipv4: validate checksum_start before completing checksum
If a packet with bad checksum metadata gets into the ipv4 stack,
skb_checksum_help can corrupt the network header and cause a bunch of
mischief.
This was discovered and reported by Paulos, and has been reporoduced
by others independently since.
We really shouldn't allow such packets in, but as a defence
in depth measure, let's also check before we complete the checksum.
A more complete validation at input is forthcoming, but needs more work.
Crítica · CVSS 9.8EPSS 0,45%Código de explotación públicoSin corrección publicada
ipv4: free inet_opt and ireq_opt after an RCU grace period
In the Linux kernel, the following vulnerability has been resolved:
ipv4: free inet_opt and ireq_opt after an RCU grace period
tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the
child socket (newinet->inet_opt) without copying it.
Another cpu can concurrently process a retransmitted SYN for the same
request socket, and send a SYNACK from tcp_check_req().
tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt
under rcu_read_lock() only, and ip_build_and_send_pkt() and
ip_options_build() then read opt->optlen twice.
Note that the SYNACK timer itself is not an issue: it holds a
reference on its request socket, and
xen/netfront: drop RX packets with a short Ethernet header
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: drop RX packets with a short Ethernet header
handle_incoming_queue() pulls pull_to bytes into the head before
calling eth_type_trans(). pull_to is the length of the first RX slot,
capped at RX_COPY_THRESHOLD, and that length comes from the backend.
Nothing checks it against ETH_HLEN.
If the first slot is shorter than ETH_HLEN and more slots follow, the
head ends up shorter than an Ethernet header while skb->len is longer,
and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is
shorter than ETH_HLEN, eth_type_trans() reads the header past the end
smb: client: fix rlist race and missing initialization
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix rlist race and missing initialization
TCP_Server_Info.rlist is allocated via kzalloc which zeros both ->next
and ->prev to NULL instead of pointing to itself, making list_empty()
always return false and list_add() dereference a NULL ->prev pointer.
Also, cifs_signal_cifsd_for_reconnect() can be called concurrently
from multiple cifsd threads, allowing the same server's rlist node to
be added twice into the local list, corrupting it.
kernfs: link kn to its parent before the LSM init hook
In the Linux kernel, the following vulnerability has been resolved:
kernfs: link kn to its parent before the LSM init hook
After commit 12e9e3cd03b5 ("simpe_xattr: use per-sb cache"),
kernfs_xattr_set() and kernfs_xattr_get() compute the cache via
kernfs_root(kn) before any other check. kernfs_root(kn) walks
kn->__parent first and falls back to kn->dir.root, both of which are
NULL on a freshly kmem_cache_zalloc()'d kn. kn->__parent was being set
in kernfs_new_node() after __kernfs_new_node() returned, and kn->dir.root
is set even later by kernfs_create_dir_ns() / kernfs_create_empty_dir().
The LSM kernfs_init_security hook is invoked from
mm/khugepaged: write all dirty file folios when collapsing
In the Linux kernel, the following vulnerability has been resolved:
mm/khugepaged: write all dirty file folios when collapsing
[There is no upstream commit, as this code was removed by upstream
commit 044925f9b565 ("mm: fs: remove filemap_nr_thps*() functions and their users")]
As-is, khugepaged and writable-file opening exclude each other. A file
cannot be open writeable and have THPs (because the filesystem is not aware
of them). khugepaged will never collapse file pages for files that are
opened writeable. On an open(O_RDWR/O_WRONLY), the page cache for that
particular file is dropped. This is fine because nothing could've been
dirtied
can: bcm: switch timer to HRTIMER_MODE_SOFT and remove hrtimer_tasklet
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: switch timer to HRTIMER_MODE_SOFT and remove hrtimer_tasklet
This patch switches the timer to HRTIMER_MODE_SOFT, which executed the
timer callback in softirq context and removes the hrtimer_tasklet.