| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: fix metabuf leak in inode xattr initialization
commit bb88e8da0025 ("erofs: use meta buffers for xattr operations")
converted xattr operations to use on-stack erofs_buf instances.
erofs_init_inode_xattrs() uses such a metabuf while reading the inline
xattr header and shared xattr id array.
Some error paths after erofs_read_metabuf() leave through out_unlock
without dropping the metabuf, so the folio reference can leak.
Consolidate the cleanup at out_unlock. erofs_put_metabuf() is a
no-op if no folio has been acquired, and this keeps all paths after
taking EROFS_I_BL_XATTR_BIT covered by a single cleanup site. |
| In the Linux kernel, the following vulnerability has been resolved:
pds_core: fix debugfs_lookup dentry leak and error handling
debugfs_lookup() returns a dentry with an elevated reference count that
must be released with dput(). The current code discards the returned
dentry without calling dput(), causing a reference leak on every
firmware reset recovery.
Additionally, when CONFIG_DEBUG_FS is disabled, debugfs_lookup()
returns ERR_PTR(-ENODEV), not NULL. The current check passes for error
pointers and would call dput() on an invalid pointer, causing a crash. |
| In the Linux kernel, the following vulnerability has been resolved:
net: wwan: iosm: bound device offsets in the MUX downlink decoder
mux_dl_adb_decode() walks a chain of aggregated datagram tables using
offsets and lengths taken from the modem. first_table_index,
next_table_index, table_length, datagram_index and datagram_length are
all device supplied le values. Only first_table_index was checked, and
only for being non zero. The decoder then formed adth = block +
adth_index and read the table header and the datagram entries with no
bound against the received skb. A modem that reports an index or a
length past the downlink buffer makes the decoder read out of bounds.
The buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE and skb->len is at most
that, so skb->len is the real limit, but none of these in band offsets
were checked against it.
The table chain is also followed with no forward progress check. The loop
takes the next table from adth->next_table_index and stops only when that
reaches zero. A modem can stage two tables that point at each other, so
the loop never ends. It runs in softirq and clones the skb on every pass.
Validate every device offset and length against skb->len before use.
The block header must fit. Each table header, on entry and after every
next_table_index, must lie inside the skb. The datagram table must fit.
Each datagram index and length must stay inside the skb. The header
padding must not exceed the datagram length so the receive length does
not wrap. Require each next_table_index to move forward so the chain
cannot cycle.
This was reproduced under KASAN as a slab out of bounds read on a normal
downlink receive once the iosm net device is up. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_multiq: Replace direct dequeue call with peek and qdisc_dequeue_peeked
multiq_dequeue() takes a packet from a band's child with a direct
->dequeue() call after multiq_peek() peeked it. When the child is
non-work-conserving the peek stashes the skb in the child's gso_skb, so
the direct dequeue returns a different skb and orphans the stash,
desyncing the child's qlen/backlog. With a qfq child reached through a
peeking parent (e.g. tbf) this re-enters the child on an emptied list and
dereferences NULL, panicking the kernel from softirq on ordinary egress.
Take the packet through qdisc_dequeue_peeked(), as sch_prio already does
and as sch_red and sch_sfb were just fixed to do. The helper is a no-op
when the child has no stash, so a work-conserving child is unaffected. |
| In the Linux kernel, the following vulnerability has been resolved:
espintcp: use sk_msg_free_partial to fix partial send
sk_msg_free_partial() ensures consistency of the skmsg at every
iteration, without having to manually handle uncharges and offsets.
This simplifies the code, and fixes some bugs in skmsg accounting when
we don't send the full contents. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ipip: require CAP_NET_ADMIN in the device netns for changelink
ipip_changelink() operates on at most two netns, dev_net(dev) and the
tunnel link netns t->net. They differ once the device is created in or
moved to a netns other than the one the request runs in. The rtnl
changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a
caller privileged there but not in t->net can rewrite a tunnel that
lives in t->net.
Gate ipip_changelink() on rtnl_dev_link_net_capable() at its top,
before any attribute is parsed. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink
vti_changelink() operates on at most two netns, dev_net(dev) and the
tunnel link netns t->net. They differ once the device is created in or
moved to a netns other than the one the request runs in. The rtnl
changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a
caller privileged there but not in t->net can rewrite a tunnel that
lives in t->net.
Gate vti_changelink() on rtnl_dev_link_net_capable() at its top,
before any attribute is parsed. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink
vti6_changelink() operates on at most two netns, dev_net(dev) and the
tunnel link netns t->net. They differ once the device is created in or
moved to a netns other than the one the request runs in. The rtnl
changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a
caller privileged there but not in t->net can rewrite a tunnel that
lives in t->net.
Gate vti6_changelink() on rtnl_dev_link_net_capable() at its top,
before any attribute is parsed. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: preserve tc_skb_cb across defragmentation
tcf_ct_handle_fragments() calls nf_ct_handle_fragments() without saving
and restoring skb->cb. The defrag helper clears IPCB/IP6CB, which aliases
the tc_skb_cb/qdisc_skb_cb control buffer. Fragmented traffic through
act_ct therefore loses qdisc metadata such as pkt_segs and can trigger
WARN_ON_ONCE() in qdisc_pkt_segs() when panic_on_warn is enabled.
Save and restore the full tc_skb_cb around nf_ct_handle_fragments(),
matching the pattern used by ovs_ct_handle_fragments(). |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: modedb: fix a possible UAF in fb_find_mode()
If mode_option is NULL, it is assigned from mode_option_buf:
if (!mode_option) {
fb_get_options(NULL, &mode_option_buf);
mode_option = mode_option_buf;
}
Later, name is assigned from mode_option:
const char *name = mode_option;
However, mode_option_buf is freed before name is no longer used:
kfree(mode_option_buf);
while name is still accessed by:
if ((name_matches(db[i], name, namelen) ||
Since name aliases mode_option_buf, this may result in a
use-after-free.
Fix this by extending the lifetime of mode_option_buf until the end of the
function by using scope-based resource management for cleanup. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix use-after-free in amdxdna_gem_dmabuf_mmap()
When vm_insert_pages() fails, the error path calls vma->vm_ops->close(vma)
which internally calls drm_gem_vm_close() → drm_gem_object_put(),
releasing the GEM object reference acquired at the start of the function.
However, the close_vma label then falls through to put_obj, which calls
drm_gem_object_put() a second time on the same object.
If the first put releases the last reference, the object is freed and the
second put accesses freed memory, causing a use-after-free.
Fix by returning directly from close_vma instead of falling through to
put_obj, since the close handler already performs all necessary cleanup
including the object put. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass
In log_replay()'s analysis pass, after find_dp() returns a
valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple,
the copy_lcns block walks lrh->lcns_follow further entries:
t16 = le16_to_cpu(lrh->lcns_follow);
for (i = 0; i < t16; i++) {
size_t j = (size_t)(le64_to_cpu(lrh->target_vcn) -
le64_to_cpu(dp->vcn));
dp->page_lcns[j + i] = lrh->page_lcns[i];
}
find_dp() only validates that target_vcn falls within
[dp->vcn, dp->vcn + dp->lcns_follow), i.e., that the FIRST
cluster is covered. The walk through the further entries is
not bounded against dp->lcns_follow. For a malformed LRH
where target_vcn = dp->vcn + dp->lcns_follow - 1 and
lrh->lcns_follow > 1, the i > 0 writes overflow the dp's
allocated page_lcns[] array.
Add the missing j + lrh->lcns_follow <= dp->lcns_follow guard.
Reproduced under UML+KASAN on mainline 8d90b09e6741 as a
slab-out-of-bounds write of size 8 from log_replay+0x68d4 on
the mount path.
This is distinct from Pavitra Jha's 2026-05-02 patch
("fs/ntfs3: validate lcns_follow in log_replay conversion",
<20260502154252.164586-1-jhapavitra98@gmail.com>) which
addresses the separate version-0 dirty-page-table conversion
path's memmove(&dp->vcn, ...) call. The two fixes are
complementary; both should land.
[almaz.alexandrovich@paragon-software.com: clang-formatted the changes,
fixed conflicts] |
| In the Linux kernel, the following vulnerability has been resolved:
batman-adv: tt: prevent TVLV OOB check overflow
A TT unicast TVLV contains the number of VLANs stored in it. This number is
an u16 and gets multiplied by the size of the struct
batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16
used to store the tt_vlan_len. All additional safety checks to prevent
out-of-bounds access of the TVLV buffer are invalid due to this overflow.
Using size_t prevents this overflow and ensures that the safety checks
compare against the actual buffer requirements. |
| In affected versions of Octopus Deploy Insufficient checks on the project trigger actions allows an unauthorized user to trigger a deployment. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag
nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6
fragment header and then unconditionally advances skb->mac_header:
skb->mac_header += sizeof(struct frag_hdr);
On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header
yet, so skb->mac_header is still the "not set" sentinel (u16)~0U. Adding
sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7),
after which skb_mac_header_was_set() wrongly reports a MAC header is
present and skb_mac_header() points into the headroom.
The reassembler has done this unconditional add since it was introduced;
it was harmless while mac_header was a bare pointer, but wrong once
mac_header became a u16 offset whose unset state is the ~0U sentinel
tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c
does the same relocation and does guard the adjustment; mirror the
guard here. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: don't leak bad clone into future transaction
On memory allocation failure the cloned nft_pipapo_match can enter a bad
state:
- some fields can have their lookup tables resized while others did
not
- bits might have been toggled
- scratch map can be undersized which also means m->bsize_max can be
lower than what is required
This means that the next insertion in the same batch can trigger
out-of-bounds writes.
Furthermore, a failure in the first can result in the bad clone to
leak into the next transaction because the abort callback is never
executed in this case (the upper layer saw an error and no attempt to
allocate a transactional request was made).
Record a state for the nft_pipapo_match structure:
- NEW (pristine clone)
- MOD (modified clone with good state)
- ERR (potentially bogus content)
Then make it so that deletes and insertions fail when the clone
entered ERR state.
In case the very first insert attempt results in an error, free the
clone right away. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory
When constructing an L1 VNCR mapping, KVM unconditionally uses cacheable
memory attributes, even if the underlying PFN isn't memory. This gets
particularly hairy if the endpoint doesn't support cacheable memory
attributes, potentially throwing an SError on writeback...
While KVM does permit cacheable memory attributes on certain PFNMAP
VMAs, kvm_translate_vncr() isn't currently grabbing the VMA. So do the
simpler thing for now and just reject everything that isn't memory. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR
KVM currently maps the L1 VNCR into the host stage-1 by relying entirely
on the permissions of the guest stage-1. At the same time, it is
entirely possible that the backing PFN is read-only (e.g. RO memslot),
meaning that the L1 VNCR should use at most a read-only mapping.
Cache the writability of the PFN in the VNCR TLB and use it to constrain
the resulting fixmap permissions. Promote VNCR permission faults to an
SEA in the case where the guest attempts to write to a read-only
endpoint. Conveniently, this also plugs a page leak found by Sashiko [*]
resulting from the early return for a read-only PFN. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs
Ignore KVM's internal "service pending PV EOI" request if the vCPU has
disabled PV EOIs since the request was made. Asserting that PV EOIs are
enabled can fail if reading guest memory in pv_eoi_get_user() fails, i.e.
if pv_eoi_test_and_clr_pending() bails early, *and* the vCPU also disables
PV EOIs.
kernel BUG at arch/x86/kvm/lapic.c:3338!
Oops: invalid opcode: 0000 [#1] SMP
CPU: 4 UID: 1000 PID: 890 Comm: pv_eoi_test Not tainted 7.0.0-d585aa5894d8-vm #337 PREEMPT
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:kvm_lapic_sync_from_vapic+0x12b/0x140 [kvm]
Call Trace:
<TASK>
kvm_arch_vcpu_ioctl_run+0x1075/0x1c30 [kvm]
kvm_vcpu_ioctl+0x2d5/0x980 [kvm]
__x64_sys_ioctl+0x8a/0xd0
do_syscall_64+0xb5/0xb40
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
Modules linked in: kvm_intel kvm irqbypass
---[ end trace 0000000000000000 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: restrict socket queue dumps in enqueue tracepoints
tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is
owned by user context. The spinlock protects the backlog queue in this
path, but it does not serialize against the socket owner consuming or
purging sk_receive_queue.
KASAN reported:
CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123
print_report+0xce/0x5b0 mm/kasan/report.c:482
kasan_report+0xc6/0x100 mm/kasan/report.c:597
__asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380
tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73
tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187
tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996
trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188
tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497
tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689
__tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512
tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400
sock_sendmsg+0x2f6/0x3e0 net/socket.c:825
splice_to_socket+0x7f9/0x1010 fs/splice.c:884
do_splice+0xe21/0x2330 fs/splice.c:936
__do_splice+0x153/0x260 fs/splice.c:1431
__x64_sys_splice+0x150/0x230 fs/splice.c:1616
x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41
do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63
entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130
RIP: 0033:0x71624e8aafe2
Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66
RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113
RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2
RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066
RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00
R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40
</TASK>
The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump
sk_receive_queue and can therefore dereference skbs that the socket
owner has already dequeued or freed. Restrict these dumps to
TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held
spinlock.
Keep the change limited to the enqueue path, where the unsafe queue dump
is reachable while the socket is owned by user context. |
