| CVE-2014-6393 |
The Express web framework
before 3.11 and 4.x before 4.5 for Node.js does
not provide a charset field in HTTP Content-Type
headers in 400 level responses, which might allow
remote attackers to conduct cross-site scripting
(XSS) attacks via characters in a non-standard
encoding. |
| CVE-2022-24999 |
qs before 6.10.3, as used in
Express before 4.17.3 and other products, allows
attackers to cause a Node process hang for an
Express application because an __ proto__ key can
be used. In many typical Express use cases, an
unauthenticated remote attacker can place the
attack payload in the query string of the URL that
is used to visit the application, such as
a[__proto__]=b&a[__proto__]&a[length]=100000000.
The fix was backported to qs 6.9.7, 6.8.3, 6.7.3,
6.6.1, 6.5.3, 6.4.1, 6.3.3, and 6.2.4 (and
therefore Express 4.17.3, which has "deps:
qs@6.9.7" in its release description, is not
vulnerable). |
| CVE-2023-1428 |
There exists an vulnerability
causing an abort() to be called in gRPC. The
following headers cause gRPC's C++ implementation
to abort() when called via http2: te: x (x !=
trailers) :scheme: x (x != http, https)
grpclb_client_stats: x (x == anything) On top of
sending one of those headers, a later header must
be sent that gets the total header size past 8KB.
We recommend upgrading past git
commit 2485fa94bd8a723e5c977d55a3ce10b301b437f8 or
v1.53 and above. |
| CVE-2023-39327 |
A flaw was found in OpenJPEG.
Maliciously constructed pictures can cause the
program to enter a large loop and continuously
print warning messages on the terminal. |
| CVE-2024-10491 |
A vulnerability has been
identified in the Express response.links function,
allowing for arbitrary resource injection in the
Link header when unsanitized data is used. The
issue arises from improper sanitization in `Link`
header values, which can allow a combination of
characters like `,`, `;`, and `<>` to
preload malicious resources. This vulnerability is
especially relevant for dynamic
parameters. |
| CVE-2024-29041 |
Express.js minimalist web
framework for node. Versions of Express.js prior
to 4.19.0 and all pre-release alpha and beta
versions of 5.0 are affected by an open redirect
vulnerability using malformed URLs. When a user of
Express performs a redirect using a user-provided
URL Express performs an encode [using
`encodeurl`](https://github.com/pillarjs/encodeurl)
on the contents before passing it to the
`location` header. This can cause malformed URLs
to be evaluated in unexpected ways by common
redirect allow list implementations in Express
applications, leading to an Open Redirect via
bypass of a properly implemented allow list. The
main method impacted is `res.location()` but this
is also called from within `res.redirect()`. The
vulnerability is fixed in 4.19.2 and
5.0.0-beta.3. |
| CVE-2024-43796 |
Express.js minimalist web
framework for node. In express < 4.20.0,
passing untrusted user input - even after
sanitizing it - to response.redirect() may execute
untrusted code. This issue is patched in express
4.20.0. |
| CVE-2024-50004 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amd/display: update DML2 policy
EnhancedPrefetchScheduleAccelerationFinal DCN35
[WHY & HOW] Mismatch in DCN35 DML2 cause bw
validation failed to acquire unexpected DPP pipe
to cause grey screen and system hang. Remove
EnhancedPrefetchScheduleAccelerationFinal value
override to match HW spec. (cherry picked from
commit
9dad21f910fcea2bdcff4af46159101d7f9cd8ba) |
| CVE-2024-56406 |
A heap buffer overflow
vulnerability was discovered in Perl. Release
branches 5.34, 5.36, 5.38 and 5.40 are affected,
including development versions from 5.33.1 through
5.41.10. When there are non-ASCII bytes in the
left-hand-side of the `tr` operator,
`S_do_trans_invmap` can overflow the destination
pointer `d`. $ perl -e '$_ = "\x{FF}" x
1000000; tr/\xFF/\x{100}/;' Segmentation fault
(core dumped) It is believed that this
vulnerability can enable Denial of Service and
possibly Code Execution attacks on platforms that
lack sufficient defenses. |
| CVE-2024-58096 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
ath11k: add srng->lock for ath11k_hal_srng_* in
monitor mode ath11k_hal_srng_* should be used with
srng->lock to protect srng data. For
ath11k_dp_rx_mon_dest_process() and
ath11k_dp_full_mon_process_rx(), they use
ath11k_hal_srng_* for many times but never call
srng->lock. So when running (full) monitor
mode, warning will occur: RIP:
0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30
[ath11k]
ath11k_dp_rx_process_mon_status+0xc45/0x1190
[ath11k] ? idr_alloc_u32+0x97/0xd0
ath11k_dp_rx_process_mon_rings+0x32a/0x550
[ath11k] ath11k_dp_service_srng+0x289/0x5a0
[ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0
[ath11k] __napi_poll+0x30/0x1f0
net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319
So add srng->lock for them to avoid such
warnings. Inorder to fetch the srng->lock,
should change srng's definition from 'void' to
'struct hal_srng'. And initialize them elsewhere
to prevent one line of code from being too long.
This is consistent with other ring process
functions, such as ath11k_dp_process_rx().
Tested-on: WCN6855 hw2.0 PCI
WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI
WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 |
| CVE-2024-58097 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
ath11k: fix RCU stall while reaping monitor
destination ring While processing the monitor
destination ring, MSDUs are reaped from the link
descriptor based on the corresponding buf_id.
However, sometimes the driver cannot obtain a
valid buffer corresponding to the buf_id received
from the hardware. This causes an infinite loop in
the destination processing, resulting in a kernel
crash. kernel log: ath11k_pci 0000:58:00.0: data
msdu_pop: invalid buf_id 309 ath11k_pci
0000:58:00.0: data dp_rx_monitor_link_desc_return
failed ath11k_pci 0000:58:00.0: data msdu_pop:
invalid buf_id 309 ath11k_pci 0000:58:00.0: data
dp_rx_monitor_link_desc_return failed Fix this by
skipping the problematic buf_id and reaping the
next entry, replacing the break with the next MSDU
processing. Tested-on: WCN6855 hw2.0 PCI
WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI
WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 |
| CVE-2025-1390 |
The PAM module pam_cap.so of
libcap configuration supports group names starting
with “@”, during actual parsing, configurations
not starting with “@” are incorrectly recognized
as group names. This may result in nonintended
users being granted an inherited capability set,
potentially leading to security risks. Attackers
can exploit this vulnerability to achieve local
privilege escalation on systems where
/etc/security/capability.conf is used to configure
user inherited privileges by constructing specific
usernames. |
| CVE-2025-2999 |
A vulnerability was found in
PyTorch 2.6.0. It has been rated as critical.
Affected by this issue is the function
torch.nn.utils.rnn.unpack_sequence. The
manipulation leads to memory corruption. Attacking
locally is a requirement. The exploit has been
disclosed to the public and may be used. |
| CVE-2025-3000 |
A vulnerability classified as
critical has been found in PyTorch 2.6.0. This
affects the function torch.jit.script. The
manipulation leads to memory corruption. It is
possible to launch the attack on the local host.
The exploit has been disclosed to the public and
may be used. |
| CVE-2025-3001 |
A vulnerability classified as
critical was found in PyTorch 2.6.0. This
vulnerability affects the function
torch.lstm_cell. The manipulation leads to memory
corruption. The attack needs to be approached
locally. The exploit has been disclosed to the
public and may be used. |
| CVE-2025-5702 |
The strcmp implementation
optimized for the Power10 processor in the GNU C
Library version 2.39 and later writes to vector
registers v20 to v31 without saving contents from
the caller (those registers are defined as
non-volatile registers by the powerpc64le ABI),
resulting in overwriting of its contents and
potentially altering control flow of the caller,
or leaking the input strings to the function to
other parts of the program. |
| CVE-2025-6020 |
A flaw was found in linux-pam.
The module pam_namespace may use access
user-controlled paths without proper protection,
allowing local users to elevate their privileges
to root via multiple symlink attacks and race
conditions. |
| CVE-2025-14821 |
A flaw was found in libssh.
This vulnerability allows local man-in-the-middle
attacks, security downgrades of SSH (Secure Shell)
connections, and manipulation of trusted host
information, posing a significant risk to the
confidentiality, integrity, and availability of
SSH communications via an insecure default
configuration on Windows systems where the library
automatically loads configuration files from the
C:\etc directory, which can be created and
modified by unprivileged local users. |
| CVE-2025-15284 |
Improper Input Validation
vulnerability in qs (parse modules) allows HTTP
DoS.This issue affects qs: < 6.14.1. Summary
The arrayLimit option in qs did not enforce limits
for bracket notation (a[]=1&a[]=2), only for
indexed notation (a[0]=1). This is a consistency
bug; arrayLimit should apply uniformly across all
array notations. Note: The default
parameterLimit of 1000 effectively mitigates the
DoS scenario originally described. With default
options, bracket notation cannot produce arrays
larger than parameterLimit regardless of
arrayLimit, because each a[]=valueconsumes one
parameter slot. The severity has been reduced
accordingly. Details The arrayLimit option only
checked limits for indexed notation
(a[0]=1&a[1]=2) but did not enforce it for
bracket notation (a[]=1&a[]=2). Vulnerable
code (lib/parse.js:159-162): if (root === '[]'
&& options.parseArrays) { obj =
utils.combine([], leaf); // No arrayLimit check }
Working code (lib/parse.js:175): else if (index
<= options.arrayLimit) { // Limit checked here
obj = []; obj[index] = leaf; } The bracket
notation handler at line 159 uses
utils.combine([], leaf) without validating against
options.arrayLimit, while indexed notation at line
175 checks index <= options.arrayLimit before
creating arrays. PoC const qs = require('qs');
const result =
qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6',
{ arrayLimit: 5 }); console.log(result.a.length);
// Output: 6 (should be max 5) Note on
parameterLimit interaction: The original
advisory's "DoS demonstration" claimed a length of
10,000, but parameterLimit (default: 1000) caps
parsing to 1,000 parameters. With default options,
the actual output is 1,000, not 10,000. Impact
Consistency bug in arrayLimit enforcement. With
default parameterLimit, the practical DoS risk is
negligible since parameterLimit already caps the
total number of parsed parameters (and thus array
elements from bracket notation). The risk
increases only when parameterLimit is explicitly
set to a very high value. |
| CVE-2025-31115 |
XZ Utils provide a
general-purpose data-compression library plus
command-line tools. In XZ Utils 5.3.3alpha to
5.8.0, the multithreaded .xz decoder in liblzma
has a bug where invalid input can at least result
in a crash. The effects include heap use after
free and writing to an address based on the null
pointer plus an offset. Applications and libraries
that use the lzma_stream_decoder_mt function are
affected. The bug has been fixed in XZ Utils
5.8.1, and the fix has been committed to the v5.4,
v5.6, v5.8, and master branches in the xz Git
repository. No new release packages will be made
from the old stable branches, but a standalone
patch is available that applies to all affected
releases. |
| CVE-2025-32989 |
A heap-buffer-overread
vulnerability was found in GnuTLS in how it
handles the Certificate Transparency (CT) Signed
Certificate Timestamp (SCT) extension during X.509
certificate parsing. This flaw allows a malicious
user to create a certificate containing a
malformed SCT extension (OID
1.3.6.1.4.1.11129.2.4.2) that contains sensitive
data. This issue leads to the exposure of
confidential information when GnuTLS verifies
certificates from certain websites when the
certificate (SCT) is not checked
correctly. |
| CVE-2025-37926 |
In the Linux kernel, the
following vulnerability has been resolved: ksmbd:
fix use-after-free in ksmbd_session_rpc_open A UAF
issue can occur due to a race condition between
ksmbd_session_rpc_open() and
__session_rpc_close(). Add rpc_lock to the session
to protect it. |
| CVE-2025-38201 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map
bucket size to INT_MAX Otherwise, it is possible
to hit WARN_ON_ONCE in __kvmalloc_node_noprof()
when resizing hashtable because __GFP_NOWARN is
unset. Similar to: b541ba7d1f5a ("netfilter:
conntrack: clamp maximum hashtable size to
INT_MAX") |
| CVE-2025-38591 |
In the Linux kernel, the
following vulnerability has been resolved: bpf:
Reject narrower access to pointer ctx fields The
following BPF program, simplified from a syzkaller
repro, causes a kernel warning: r0 = *(u8 *)(r1 +
169); exit; With pointer field sk being at offset
168 in __sk_buff. This access is detected as a
narrower read in bpf_skb_is_valid_access because
it doesn't match offsetof(struct __sk_buff, sk).
It is therefore allowed and later proceeds to
bpf_convert_ctx_access. Note that for the
"is_narrower_load" case in the
convert_ctx_accesses(), the insn->off is
aligned, so the cnt may not be 0 because it
matches the offsetof(struct __sk_buff, sk) in the
bpf_convert_ctx_access. However, the target_size
stays 0 and the verifier errors with a kernel
warning: verifier bug: error during ctx access
conversion(1) This patch fixes that to return a
proper "invalid bpf_context access off=X size=Y"
error on the load instruction. The same issue
affects multiple other fields in context
structures that allow narrow access. Some other
non-affected fields (for sk_msg, sk_lookup, and
sockopt) were also changed to use
bpf_ctx_range_ptr for consistency. Note this
syzkaller crash was reported in the "Closes" link
below, which used to be about a different bug,
fixed in commit fce7bd8e385a ("bpf/verifier:
Handle BPF_LOAD_ACQ instructions in
insn_def_regno()"). Because syzbot somehow
confused the two bugs, the new crash and repro
didn't get reported to the mailing list. |
| CVE-2025-40039 |
In the Linux kernel, the
following vulnerability has been resolved: ksmbd:
Fix race condition in RPC handle list access The
'sess->rpc_handle_list' XArray manages RPC
handles within a ksmbd session. Access to this
list is intended to be protected by
'sess->rpc_lock' (an rw_semaphore). However,
the locking implementation was flawed, leading to
potential race conditions. In
ksmbd_session_rpc_open(), the code incorrectly
acquired only a read lock before calling
xa_store() and xa_erase(). Since these operations
modify the XArray structure, a write lock is
required to ensure exclusive access and prevent
data corruption from concurrent modifications.
Furthermore, ksmbd_session_rpc_method() accessed
the list using xa_load() without holding any lock
at all. This could lead to reading inconsistent
data or a potential use-after-free if an entry is
concurrently removed and the pointer is
dereferenced. Fix these issues by: 1. Using
down_write() and up_write() in
ksmbd_session_rpc_open() to ensure exclusive
access during XArray modification, and ensuring
the lock is correctly released on error paths. 2.
Adding down_read() and up_read() in
ksmbd_session_rpc_method() to safely protect the
lookup. |
| CVE-2025-40082 |
In the Linux kernel, the
following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in
hfsplus_uni2asc() BUG: KASAN: slab-out-of-bounds
in hfsplus_uni2asc+0xa71/0xb90
fs/hfsplus/unicode.c:186 Read of size 2 at addr
ffff8880289ef218 by task syz.6.248/14290 CPU: 0
UID: 0 PID: 14290 Comm: syz.6.248 Not tainted
6.16.4 #1 PREEMPT(full) Hardware name: QEMU
Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
04/01/2014 Call Trace: <TASK> __dump_stack
lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378
[inline] print_report+0xca/0x5f0
mm/kasan/report.c:482 kasan_report+0xca/0x100
mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90
fs/hfsplus/unicode.c:186
hfsplus_listxattr+0x5b6/0xbd0
fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140
fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x143/0x360 fs/xattr.c:988
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xcb/0x4c0
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:
0033:0x7fe0e9fae16d Code: 02 b8 ff ff ff ff c3 66
0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89
d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05
<48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff
ff ff f7 d8 64 89 01 48 RSP: 002b:00007fe0eae67f98
EFLAGS: 00000246 ORIG_RAX: 00000000000000c3 RAX:
ffffffffffffffda RBX: 00007fe0ea205fa0 RCX:
00007fe0e9fae16d RDX: 0000000000000000 RSI:
0000000000000000 RDI: 0000200000000000 RBP:
00007fe0ea0480f0 R08: 0000000000000000 R09:
0000000000000000 R10: 0000000000000000 R11:
0000000000000246 R12: 0000000000000000 R13:
00007fe0ea206038 R14: 00007fe0ea205fa0 R15:
00007fe0eae48000 </TASK> Allocated by task
14290: kasan_save_stack+0x24/0x50
mm/kasan/common.c:47 kasan_save_track+0x14/0x30
mm/kasan/common.c:68 poison_kmalloc_redzone
mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4333 [inline]
__kmalloc_noprof+0x219/0x540 mm/slub.c:4345
kmalloc_noprof include/linux/slab.h:909 [inline]
hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21
hfsplus_listxattr+0x331/0xbd0
fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140
fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924
filename_listxattr fs/xattr.c:958 [inline]
path_listxattrat+0x143/0x360 fs/xattr.c:988
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xcb/0x4c0
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f When
hfsplus_uni2asc is called from hfsplus_listxattr,
it actually passes in a struct
hfsplus_attr_unistr*. The size of the
corresponding structure is different from that of
hfsplus_unistr, so the previous fix (94458781aee6)
is insufficient. The pointer on the unicode buffer
is still going beyond the allocated memory. This
patch introduces two warpper functions
hfsplus_uni2asc_xattr_str and hfsplus_uni2asc_str
to process two unicode buffers, struct
hfsplus_attr_unistr* and struct hfsplus_unistr*
respectively. When ustrlen value is bigger than
the allocated memory size, the ustrlen value is
limited to an safe size. |
| CVE-2025-40149 |
In the Linux kernel, the
following vulnerability has been resolved: tls:
Use __sk_dst_get() and dst_dev_rcu() in
get_netdev_for_sock(). get_netdev_for_sock() is
called during setsockopt(), so not under RCU.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dst_dev_rcu(). Note
that the only ->ndo_sk_get_lower_dev() user is
bond_sk_get_lower_dev(), which uses RCU. |
| CVE-2025-40909 |
Perl threads have a working
directory race condition where file operations may
target unintended paths. If a directory handle is
open at thread creation, the process-wide current
working directory is temporarily changed in order
to clone that handle for the new thread, which is
visible from any third (or more) thread already
running. This may lead to unintended
operations such as loading code or accessing files
from unexpected locations, which a local attacker
may be able to exploit. The bug was introduced in
commit 11a11ecf4bea72b17d250cfb43c897be1341861e
and released in Perl version 5.13.6 |
| CVE-2025-41242 |
Spring Framework MVC
applications can be vulnerable to a “Path
Traversal Vulnerability” when deployed on a
non-compliant Servlet container. An application
can be vulnerable when all the following are true:
* the application is deployed as a WAR or with an
embedded Servlet container * the Servlet container
does not reject suspicious sequences
https://jakarta.ee/specifications/servlet/6.1/jakarta-servlet-spec-6.1.html#uri-path-canonicalization
* the application serves static resources
https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title
with Spring resource handling We have verified
that applications deployed on Apache Tomcat or
Eclipse Jetty are not vulnerable, as long as
default security features are not disabled in the
configuration. Because we cannot check exploits
against all Servlet containers and configuration
variants, we strongly recommend upgrading your
application. |
| CVE-2025-49146 |
pgjdbc is an open source
postgresql JDBC Driver. From 42.7.4 and until
42.7.7, when the PostgreSQL JDBC driver is
configured with channel binding set to required
(default value is prefer), the driver would
incorrectly allow connections to proceed with
authentication methods that do not support channel
binding (such as password, MD5, GSS, or SSPI
authentication). This could allow a
man-in-the-middle attacker to intercept
connections that users believed were protected by
channel binding requirements. This vulnerability
is fixed in 42.7.7. |
| CVE-2025-54518 |
Improper isolation of shared
resources within the CPU operation cache on Zen
2-based products could allow an attacker to
corrupt instructions executed at a different
privilege level, potentially resulting in
privilege escalation. |
| CVE-2025-54798 |
tmp is a temporary file and
directory creator for node.js. In versions 0.2.3
and below, tmp is vulnerable to an arbitrary
temporary file / directory write via symbolic link
dir parameter. This is fixed in version
0.2.4. |
| CVE-2025-66019 |
pypdf is a free and
open-source pure-python PDF library. Prior to
version 6.4.0, an attacker who uses this
vulnerability can craft a PDF which leads to a
memory usage of up to 1 GB per stream. This
requires parsing the content stream of a page
using the LZWDecode filter. This issue has been
patched in version 6.4.0. |
| CVE-2025-68351 |
In the Linux kernel, the
following vulnerability has been resolved: exfat:
fix refcount leak in exfat_find Fix refcount leaks
in `exfat_find` related to `exfat_get_dentry_set`.
Function `exfat_get_dentry_set` would increase the
reference counter of `es->bh` on success.
Therefore, `exfat_put_dentry_set` must be called
after `exfat_get_dentry_set` to ensure refcount
consistency. This patch relocate two checks to
avoid possible leaks. |
| CVE-2025-68358 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
fix racy bitfield write in
btrfs_clear_space_info_full() From the
memory-barriers.txt document regarding memory
barrier ordering guarantees: (*) These guarantees
do not apply to bitfields, because compilers often
generate code to modify these using non-atomic
read-modify-write sequences. Do not attempt to use
bitfields to synchronize parallel algorithms. (*)
Even in cases where bitfields are protected by
locks, all fields in a given bitfield must be
protected by one lock. If two fields in a given
bitfield are protected by different locks, the
compiler's non-atomic read-modify-write sequences
can cause an update to one field to corrupt the
value of an adjacent field. btrfs_space_info has a
bitfield sharing an underlying word consisting of
the fields full, chunk_alloc, and flush: struct
btrfs_space_info { struct btrfs_fs_info * fs_info;
/* 0 8 */ struct btrfs_space_info * parent; /* 8 8
*/ ... int clamp; /* 172 4 */ unsigned int full:1;
/* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176:
1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...
Therefore, to be safe from parallel
read-modify-writes losing a write to one of the
bitfield members protected by a lock, all writes
to all the bitfields must use the lock. They
almost universally do, except for
btrfs_clear_space_info_full() which iterates over
the space_infos and writes out found->full = 0
without a lock. Imagine that we have one thread
completing a transaction in which we finished
deleting a block_group and are thus calling
btrfs_clear_space_info_full() while simultaneously
the data reclaim ticket infrastructure is running
do_async_reclaim_data_space(): T1 T2
btrfs_commit_transaction
btrfs_clear_space_info_full data_sinfo->full =
0 READ: full:0, chunk_alloc:0, flush:1
do_async_reclaim_data_space(data_sinfo)
spin_lock(&space_info->lock);
if(list_empty(tickets)) space_info->flush = 0;
READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE:
full: 0, chunk_alloc:0, flush:0
spin_unlock(&space_info->lock); return;
MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now
data_sinfo->flush is 1 but the reclaim worker
has exited. This breaks the invariant that flush
is 0 iff there is no work queued or running. Once
this invariant is violated, future allocations
that go into __reserve_bytes() will add tickets to
space_info->tickets but will see
space_info->flush is set to 1 and not queue the
work. After this, they will block forever on the
resulting ticket, as it is now impossible to kick
the worker again. I also confirmed by looking at
the assembly of the affected kernel that it is
doing RMW operations. For example, to set the
flush (3rd) bit to 0, the assembly is: andb
$0xfb,0x60(%rbx) and similarly for setting the
full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I
think this is really a bug on practical systems. I
have observed a number of systems in this exact
state, but am currently unable to reproduce it.
Rather than leaving this footgun lying around for
the future, take advantage of the fact that there
is room in the struct anyway, and that it is
already quite large and simply change the three
bitfield members to bools. This avoids writes to
space_info->full having any effect on
---truncated--- |
| CVE-2025-68365 |
In the Linux kernel, the
following vulnerability has been resolved:
fs/ntfs3: Initialize allocated memory before use
KMSAN reports: Multiple uninitialized values
detected: - KMSAN: uninit-value in ntfs_read_hdr
(3) - KMSAN: uninit-value in bcmp (3) Memory is
allocated by __getname(), which is a wrapper for
kmem_cache_alloc(). This memory is used before
being properly cleared. Change kmem_cache_alloc()
to kmem_cache_zalloc() to properly allocate and
clear memory before use. |
| CVE-2025-68725 |
In the Linux kernel, the
following vulnerability has been resolved: bpf: Do
not let BPF test infra emit invalid GSO types to
stack Yinhao et al. reported that their fuzzer
tool was able to trigger a skb_warn_bad_offload()
from netif_skb_features() ->
gso_features_check(). When a BPF program -
triggered via BPF test infra - pushes the packet
to the loopback device via bpf_clone_redirect()
then mentioned offload warning can be seen.
GSO-related features are then rightfully disabled.
We get into this situation due to
convert___skb_to_skb() setting gso_segs and
gso_size but not gso_type. Technically, it makes
sense that this warning triggers since the GSO
properties are malformed due to the gso_type.
Potentially, the gso_type could be marked
non-trustworthy through setting it at least to
SKB_GSO_DODGY without any other specific
assumptions, but that also feels wrong given we
should not go further into the GSO engine in the
first place. The checks were added in 121d57af308d
("gso: validate gso_type in GSO handlers") because
there were malicious (syzbot) senders that combine
a protocol with a non-matching gso_type. If we
would want to drop such packets,
gso_features_check() currently only returns
feature flags via netif_skb_features(), so one
location for potentially dropping such skbs could
be validate_xmit_unreadable_skb(), but then otoh
it would be an additional check in the fast-path
for a very corner case. Given bpf_clone_redirect()
is the only place where BPF test infra could emit
such packets, lets reject them right
there. |
| CVE-2025-68749 |
In the Linux kernel, the
following vulnerability has been resolved:
accel/ivpu: Fix race condition when unbinding BOs
Fix 'Memory manager not clean during takedown'
warning that occurs when ivpu_gem_bo_free()
removes the BO from the BOs list before it gets
unmapped. Then file_priv_unbind() triggers a
warning in drm_mm_takedown() during context
teardown. Protect the unmapping sequence with
bo_list_lock to ensure the BO is always fully
unmapped when removed from the list. This ensures
the BO is either fully unmapped at context
teardown time or present on the list and unmapped
by file_priv_unbind(). |
| CVE-2025-68803 |
In the Linux kernel, the
following vulnerability has been resolved: NFSD:
NFSv4 file creation neglects setting ACL An NFSv4
client that sets an ACL with a named principal
during file creation retrieves the ACL afterwards,
and finds that it is only a default ACL (based on
the mode bits) and not the ACL that was requested
during file creation. This violates RFC 8881
section 6.4.1.3: "the ACL attribute is set as
given". The issue occurs in nfsd_create_setattr(),
which calls nfsd_attrs_valid() to determine
whether to call nfsd_setattr(). However,
nfsd_attrs_valid() checks only for iattr changes
and security labels, but not POSIX ACLs. When only
an ACL is present, the function returns false,
nfsd_setattr() is skipped, and the POSIX ACL is
never applied to the inode. Subsequently, when the
client retrieves the ACL, the server finds no
POSIX ACL on the inode and returns one generated
from the file's mode bits rather than returning
the originally-specified ACL. |
| CVE-2025-68823 |
In the Linux kernel, the
following vulnerability has been resolved: ublk:
fix deadlock when reading partition table When one
process(such as udev) opens ublk block device
(e.g., to read the partition table via
bdev_open()), a deadlock[1] can occur: 1.
bdev_open() grabs disk->open_mutex 2. The
process issues read I/O to ublk backend to read
partition table 3. In __ublk_complete_rq(),
blk_update_request() or blk_mq_end_request() runs
bio->bi_end_io() callbacks 4. If this triggers
fput() on file descriptor of ublk block device,
the work may be deferred to current task's task
work (see fput() implementation) 5. This
eventually calls blkdev_release() from the same
context 6. blkdev_release() tries to grab
disk->open_mutex again 7. Deadlock: same task
waiting for a mutex it already holds The fix is to
run blk_update_request() and blk_mq_end_request()
with bottom halves disabled. This forces
blkdev_release() to run in kernel work-queue
context instead of current task work context, and
allows ublk server to make forward progress, and
avoids the deadlock. [axboe: rewrite comment in
ublk] |
| CVE-2025-71160 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nf_tables: avoid chain re-validation if
possible Hamza Mahfooz reports cpu soft lock-ups
in nft_chain_validate(): watchdog: BUG: soft
lockup - CPU#1 stuck for 27s!
[iptables-nft-re:37547] [..] RIP:
0010:nft_chain_validate+0xcb/0x110 [nf_tables]
[..] nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_table_validate+0x6b/0xb0 [nf_tables]
nf_tables_validate+0x8b/0xa0 [nf_tables]
nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..]
Currently nf_tables will traverse the entire table
(chain graph), starting from the entry points
(base chains), exploring all possible paths (chain
jumps). But there are cases where we could avoid
revalidation. Consider: 1 input -> j2 -> j3
2 input -> j2 -> j3 3 input -> j1 ->
j2 -> j3 Then the second rule does not need to
revalidate j2, and, by extension j3, because this
was already checked during validation of the first
rule. We need to validate it only for rule 3. This
is needed because chain loop detection also
ensures we do not exceed the jump stack: Just
because we know that j2 is cycle free, its last
jump might now exceed the allowed stack size. We
also need to update all reachable chains with the
new largest observed call depth. Care has to be
taken to revalidate even if the chain depth won't
be an issue: chain validation also ensures that
expressions are not called from invalid base
chains. For example, the masquerade expression can
only be called from NAT postrouting base chains.
Therefore we also need to keep record of the base
chain context (type, hooknum) and revalidate if
the chain becomes reachable from a different hook
location. |
| CVE-2025-71162 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: tegra-adma: Fix use-after-free A
use-after-free bug exists in the Tegra ADMA driver
when audio streams are terminated, particularly
during XRUN conditions. The issue occurs when the
DMA buffer is freed by tegra_adma_terminate_all()
before the vchan completion tasklet finishes
accessing it. The race condition follows this
sequence: 1. DMA transfer completes, triggering an
interrupt that schedules the completion tasklet
(tasklet has not executed yet) 2. Audio playback
stops, calling tegra_adma_terminate_all() which
frees the DMA buffer memory via kfree() 3. The
scheduled tasklet finally executes, calling
vchan_complete() which attempts to access the
already-freed memory Since tasklets can execute at
any time after being scheduled, there is no
guarantee that the buffer will remain valid when
vchan_complete() runs. Fix this by properly
synchronizing the virtual channel completion: -
Calling vchan_terminate_vdesc() in
tegra_adma_stop() to mark the descriptors as
terminated instead of freeing the descriptor. -
Add the callback tegra_adma_synchronize() that
calls vchan_synchronize() which kills any pending
tasklets and frees any terminated descriptors.
Crash logs: [ 337.427523] BUG: KASAN:
use-after-free in vchan_complete+0x124/0x3b0 [
337.427544] Read of size 8 at addr
ffff000132055428 by task swapper/0/0 [ 337.427562]
Call trace: [ 337.427564] dump_backtrace+0x0/0x320
[ 337.427571] show_stack+0x20/0x30 [ 337.427575]
dump_stack_lvl+0x68/0x84 [ 337.427584]
print_address_description.constprop.0+0x74/0x2b8 [
337.427590] kasan_report+0x1f4/0x210 [ 337.427598]
__asan_load8+0xa0/0xd0 [ 337.427603]
vchan_complete+0x124/0x3b0 [ 337.427609]
tasklet_action_common.constprop.0+0x190/0x1d0 [
337.427617] tasklet_action+0x30/0x40 [ 337.427623]
__do_softirq+0x1a0/0x5c4 [ 337.427628]
irq_exit+0x110/0x140 [ 337.427633]
handle_domain_irq+0xa4/0xe0 [ 337.427640]
gic_handle_irq+0x64/0x160 [ 337.427644]
call_on_irq_stack+0x20/0x4c [ 337.427649]
do_interrupt_handler+0x7c/0x90 [ 337.427654]
el1_interrupt+0x30/0x80 [ 337.427659]
el1h_64_irq_handler+0x18/0x30 [ 337.427663]
el1h_64_irq+0x7c/0x80 [ 337.427667]
cpuidle_enter_state+0xe4/0x540 [ 337.427674]
cpuidle_enter+0x54/0x80 [ 337.427679]
do_idle+0x2e0/0x380 [ 337.427685]
cpu_startup_entry+0x2c/0x70 [ 337.427690]
rest_init+0x114/0x130 [ 337.427695]
arch_call_rest_init+0x18/0x24 [ 337.427702]
start_kernel+0x380/0x3b4 [ 337.427706]
__primary_switched+0xc0/0xc8 |
| CVE-2025-71163 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: idxd: fix device leaks on compat bind
and unbind Make sure to drop the reference taken
when looking up the idxd device as part of the
compat bind and unbind sysfs interface. |
| CVE-2025-71176 |
pytest through 9.0.2 on UNIX
relies on directories with the
/tmp/pytest-of-{user} name pattern, which allows
local users to cause a denial of service or
possibly gain privileges. |
| CVE-2025-71180 |
In the Linux kernel, the
following vulnerability has been resolved:
counter: interrupt-cnt: Drop IRQF_NO_THREAD flag
An IRQ handler can either be IRQF_NO_THREAD or
acquire spinlock_t, as
CONFIG_PROVE_RAW_LOCK_NESTING warns:
============================= [ BUG: Invalid wait
context ] 6.18.0-rc1+git... #1
-----------------------------
some-user-space-process/1251 is trying to lock:
(&counter->events_list_lock){....}-{3:3},
at: counter_push_event [counter] other info that
might help us debug this: context-{2:2} no locks
held by some-user-space-process/.... stack
backtrace: CPU: 0 UID: 0 PID: 1251 Comm:
some-user-space-process 6.18.0-rc1+git... #1
PREEMPT Call trace: show_stack (C) dump_stack_lvl
dump_stack __lock_acquire lock_acquire
_raw_spin_lock_irqsave counter_push_event
[counter] interrupt_cnt_isr [interrupt_cnt]
__handle_irq_event_percpu handle_irq_event
handle_simple_irq handle_irq_desc
generic_handle_domain_irq gpio_irq_handler
handle_irq_desc generic_handle_domain_irq
gic_handle_irq call_on_irq_stack
do_interrupt_handler el0_interrupt
__el0_irq_handler_common el0t_64_irq_handler
el0t_64_irq ... and Sebastian correctly points
out. Remove IRQF_NO_THREAD as an alternative to
switching to raw_spinlock_t, because the latter
would limit all potential nested locks to
raw_spinlock_t only. |
| CVE-2025-71182 |
In the Linux kernel, the
following vulnerability has been resolved: can:
j1939: make j1939_session_activate() fail if
device is no longer registered syzbot is still
reporting unregister_netdevice: waiting for vcan0
to become free. Usage count = 2 even after commit
93a27b5891b8 ("can: j1939: add missing calls in
NETDEV_UNREGISTER notification handler") was
added. A debug printk() patch found that
j1939_session_activate() can succeed even after
j1939_cancel_active_session() from
j1939_netdev_notify(NETDEV_UNREGISTER) has
completed. Since j1939_cancel_active_session() is
processed with the session list lock held,
checking ndev->reg_state in
j1939_session_activate() with the session list
lock held can reliably close the race
window. |
| CVE-2025-71183 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
always detect conflicting inodes when logging
inode refs After rename exchanging (either with
the rename exchange operation or regular renames
in multiple non-atomic steps) two inodes and at
least one of them is a directory, we can end up
with a log tree that contains only of the inodes
and after a power failure that can result in an
attempt to delete the other inode when it should
not because it was not deleted before the power
failure. In some case that delete attempt fails
when the target inode is a directory that contains
a subvolume inside it, since the log replay code
is not prepared to deal with directory entries
that point to root items (only inode items). 1) We
have directories "dir1" (inode A) and "dir2"
(inode B) under the same parent directory; 2) We
have a file (inode C) under directory "dir1"
(inode A); 3) We have a subvolume inside directory
"dir2" (inode B); 4) All these inodes were
persisted in a past transaction and we are
currently at transaction N; 5) We rename the file
(inode C), so at btrfs_log_new_name() we update
inode C's last_unlink_trans to N; 6) We get a
rename exchange for "dir1" (inode A) and "dir2"
(inode B), so after the exchange "dir1" is inode B
and "dir2" is inode A. During the rename exchange
we call btrfs_log_new_name() for inodes A and B,
but because they are directories, we don't update
their last_unlink_trans to N; 7) An fsync against
the file (inode C) is done, and because its inode
has a last_unlink_trans with a value of N we log
its parent directory (inode A) (through
btrfs_log_all_parents(), called from
btrfs_log_inode_parent()). 8) So we end up with
inode B not logged, which now has the old name of
inode A. At copy_inode_items_to_log(), when
logging inode A, we did not check if we had any
conflicting inode to log because inode A has a
generation lower than the current transaction
(created in a past transaction); 9) After a power
failure, when replaying the log tree, since we
find that inode A has a new name that conflicts
with the name of inode B in the fs tree, we
attempt to delete inode B... this is wrong since
that directory was never deleted before the power
failure, and because there is a subvolume inside
that directory, attempting to delete it will fail
since replay_dir_deletes() and
btrfs_unlink_inode() are not prepared to deal with
dir items that point to roots instead of inodes.
When that happens the mount fails and we get a
stack trace like the following: [87.2314] BTRFS
info (device dm-0): start tree-log replay
[87.2318] BTRFS critical (device dm-0): failed to
delete reference to subvol, root 5 inode 256
parent 259 [87.2332] ------------[ cut here
]------------ [87.2338] BTRFS: Transaction aborted
(error -2) [87.2346] WARNING: CPU: 1 PID: 638968
at fs/btrfs/inode.c:4345
__btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2368]
Modules linked in: btrfs loop dm_thin_pool (...)
[87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount
Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2
PREEMPT(full) [87.2489] Tainted: [W]=WARN
[87.2494] Hardware name: QEMU Standard PC (i440FX
+ PIIX, 1996), BIOS
rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org
04/01/2014 [87.2514] RIP:
0010:__btrfs_unlink_inode+0x416/0x440 [btrfs]
[87.2538] Code: c0 89 04 24 (...) [87.2568] RSP:
0018:ffffc0e741f4b9b8 EFLAGS: 00010286 [87.2574]
RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX:
0000000000000000 [87.2582] RDX: 0000000000000002
RSI: ffffffff84ab45a1 RDI: 00000000ffffffff
[87.2591] RBP: ffff9d3ec8a6ef20 R08:
0000000000000000 R09: ffffc0e741f4b840 [87.2599]
R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12:
ffff9d3ee26d77e0 [87.2608] R13: ffffc0e741f4ba98
R14: ffff9d4458040800 R15: ffff9d44b6b7ca10
[87.2618] FS: 00007f7b9603a840(0000)
GS:ffff9d4658982000(0000) knlGS:0000000000000000
[87. ---truncated--- |
| CVE-2025-71184 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
fix NULL dereference on root when tracing inode
eviction When evicting an inode the first thing we
do is to setup tracing for it, which implies
fetching the root's id. But in btrfs_evict_inode()
the root might be NULL, as implied in the next
check that we do in btrfs_evict_inode(). Hence, we
either should set the ->root_objectid to 0 in
case the root is NULL, or we move tracing setup
after checking that the root is not NULL. Setting
the rootid to 0 at least gives us the possibility
to trace this call even in the case when the root
is NULL, so that's the solution taken
here. |
| CVE-2025-71185 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: ti: dma-crossbar: fix device leak on
am335x route allocation Make sure to drop the
reference taken when looking up the crossbar
platform device during am335x route
allocation. |
| CVE-2025-71186 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: stm32: dmamux: fix device leak on route
allocation Make sure to drop the reference taken
when looking up the DMA mux platform device during
route allocation. Note that holding a reference to
a device does not prevent its driver data from
going away so there is no point in keeping the
reference. |
| CVE-2025-71188 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: lpc18xx-dmamux: fix device leak on
route allocation Make sure to drop the reference
taken when looking up the DMA mux platform device
during route allocation. Note that holding a
reference to a device does not prevent its driver
data from going away so there is no point in
keeping the reference. |
| CVE-2025-71189 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: dw: dmamux: fix OF node leak on route
allocation failure Make sure to drop the reference
taken to the DMA master OF node also on late route
allocation failures. |
| CVE-2025-71190 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: bcm-sba-raid: fix device leak on probe
Make sure to drop the reference taken when looking
up the mailbox device during probe on probe
failures and on driver unbind. |
| CVE-2025-71191 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: at_hdmac: fix device leak on
of_dma_xlate() Make sure to drop the reference
taken when looking up the DMA platform device
during of_dma_xlate() when releasing channel
resources. Note that commit 3832b78b3ec2
("dmaengine: at_hdmac: add missing put_device()
call in at_dma_xlate()") fixed the leak in a
couple of error paths but the reference is still
leaking on successful allocation. |
| CVE-2025-71192 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
ac97: fix a double free in
snd_ac97_controller_register() If
ac97_add_adapter() fails, put_device() is the
correct way to drop the device reference. kfree()
is not required. Add kfree() if idr_alloc() fails
and in ac97_adapter_release() to do the cleanup.
Found by code review. |
| CVE-2025-71193 |
In the Linux kernel, the
following vulnerability has been resolved: phy:
qcom-qusb2: Fix NULL pointer dereference on early
suspend Enabling runtime PM before attaching the
QPHY instance as driver data can lead to a NULL
pointer dereference in runtime PM callbacks that
expect valid driver data. There is a small window
where the suspend callback may run after PM
runtime enabling and before runtime forbid. This
causes a sporadic crash during boot: ``` Unable to
handle kernel NULL pointer dereference at virtual
address 00000000000000a1 [...] CPU: 0 UID: 0 PID:
11 Comm: kworker/0:1 Not tainted 6.16.7+ #116
PREEMPT Workqueue: pm pm_runtime_work pstate:
20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--) pc :
qusb2_phy_runtime_suspend+0x14/0x1e0
[phy_qcom_qusb2] lr :
pm_generic_runtime_suspend+0x2c/0x44 [...] ```
Attach the QPHY instance as driver data before
enabling runtime PM to prevent NULL pointer
dereference in runtime PM callbacks. Reorder
pm_runtime_enable() and pm_runtime_forbid() to
prevent a short window where an unnecessary
runtime suspend can occur. Use the devres-managed
version to ensure PM runtime is symmetrically
disabled during driver removal for proper
cleanup. |
| CVE-2025-71194 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
fix deadlock in wait_current_trans() due to
ignored transaction type When wait_current_trans()
is called during start_transaction(), it currently
waits for a blocked transaction without
considering whether the given transaction type
actually needs to wait for that particular
transaction state. The btrfs_blocked_trans_types[]
array already defines which transaction types
should wait for which transaction states, but this
check was missing in wait_current_trans(). This
can lead to a deadlock scenario involving two
transactions and pending ordered extents: 1.
Transaction A is in TRANS_STATE_COMMIT_DOING state
2. A worker processing an ordered extent calls
start_transaction() with TRANS_JOIN 3.
join_transaction() returns -EBUSY because
Transaction A is in TRANS_STATE_COMMIT_DOING 4.
Transaction A moves to TRANS_STATE_UNBLOCKED and
completes 5. A new Transaction B is created
(TRANS_STATE_RUNNING) 6. The ordered extent from
step 2 is added to Transaction B's pending ordered
extents 7. Transaction B immediately starts commit
by another task and enters
TRANS_STATE_COMMIT_START 8. The worker finally
reaches wait_current_trans(), sees Transaction B
in TRANS_STATE_COMMIT_START (a blocked state), and
waits unconditionally 9. However, TRANS_JOIN
should NOT wait for TRANS_STATE_COMMIT_START
according to btrfs_blocked_trans_types[] 10.
Transaction B is waiting for pending ordered
extents to complete 11. Deadlock: Transaction B
waits for ordered extent, ordered extent waits for
Transaction B This can be illustrated by the
following call stacks: CPU0 CPU1
btrfs_finish_ordered_io()
start_transaction(TRANS_JOIN) join_transaction() #
-EBUSY (Transaction A is #
TRANS_STATE_COMMIT_DOING) # Transaction A
completes # Transaction B created # ordered extent
added to # Transaction B's pending list
btrfs_commit_transaction() # Transaction B enters
# TRANS_STATE_COMMIT_START # waiting for pending
ordered # extents wait_current_trans() # waits for
Transaction B # (should not wait!) Task
bstore_kv_sync in btrfs_commit_transaction waiting
for ordered extents: __schedule+0x2e7/0x8a0
schedule+0x64/0xe0
btrfs_commit_transaction+0xbf7/0xda0 [btrfs]
btrfs_sync_file+0x342/0x4d0 [btrfs]
__x64_sys_fdatasync+0x4b/0x80
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9 Task
kworker in wait_current_trans waiting for
transaction commit: Workqueue: btrfs-syno_nocow
btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0
schedule+0x64/0xe0 wait_current_trans+0xb0/0x110
[btrfs] start_transaction+0x346/0x5b0 [btrfs]
btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs]
btrfs_work_helper+0xe8/0x350 [btrfs]
process_one_work+0x1d3/0x3c0
worker_thread+0x4d/0x3e0 kthread+0x12d/0x150
ret_from_fork+0x1f/0x30 Fix this by passing the
transaction type to wait_current_trans() and
checking
btrfs_blocked_trans_types[cur_trans->state]
against the given type before deciding to wait.
This ensures that transaction types which are
allowed to join during certain blocked states will
not unnecessarily wait and cause
deadlocks. |
| CVE-2025-71195 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: xilinx: xdma: Fix regmap max_register
The max_register field is assigned the size of the
register memory region instead of the offset of
the last register. The result is that reading from
the regmap via debugfs can cause a segmentation
fault: tail
/sys/kernel/debug/regmap/xdma.1.auto/registers
Unable to handle kernel paging request at virtual
address ffff800082f70000 Mem abort info: ESR =
0x0000000096000007 EC = 0x25: DABT (current EL),
IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0
FSC = 0x07: level 3 translation fault [...] Call
trace: regmap_mmio_read32le+0x10/0x30
_regmap_bus_reg_read+0x74/0xc0
_regmap_read+0x68/0x198 regmap_read+0x54/0x88
regmap_read_debugfs+0x140/0x380
regmap_map_read_file+0x30/0x48
full_proxy_read+0x68/0xc8 vfs_read+0xcc/0x310
ksys_read+0x7c/0x120 __arm64_sys_read+0x24/0x40
invoke_syscall.constprop.0+0x64/0x108
do_el0_svc+0xb0/0xd8 el0_svc+0x38/0x130
el0t_64_sync_handler+0x120/0x138
el0t_64_sync+0x194/0x198 Code: aa1e03e9 d503201f
f9400000 8b214000 (b9400000) ---[ end trace
0000000000000000 ]--- note: tail[1217] exited with
irqs disabled note: tail[1217] exited with
preempt_count 1 Segmentation fault |
| CVE-2025-71196 |
In the Linux kernel, the
following vulnerability has been resolved: phy:
stm32-usphyc: Fix off by one in probe() The
"index" variable is used as an index into the
usbphyc->phys[] array which has
usbphyc->nphys elements. So if it is equal to
usbphyc->nphys then it is one element out of
bounds. The "index" comes from the device tree so
it's data that we trust and it's unlikely to be
wrong, however it's obviously still worth fixing
the bug. Change the > to >=. |
| CVE-2025-71197 |
In the Linux kernel, the
following vulnerability has been resolved: w1:
therm: Fix off-by-one buffer overflow in
alarms_store The sysfs buffer passed to
alarms_store() is allocated with 'size + 1' bytes
and a NUL terminator is appended. However, the
'size' argument does not account for this extra
byte. The original code then allocated 'size'
bytes and used strcpy() to copy 'buf', which
always writes one byte past the allocated buffer
since strcpy() copies until the NUL terminator at
index 'size'. Fix this by parsing the 'buf'
parameter directly using simple_strtoll() without
allocating any intermediate memory or string
copying. This removes the overflow while
simplifying the code. |
| CVE-2025-71198 |
In the Linux kernel, the
following vulnerability has been resolved: iio:
imu: st_lsm6dsx: fix iio_chan_spec for sensors
without event detection The
st_lsm6dsx_acc_channels array of struct
iio_chan_spec has a non-NULL event_spec field,
indicating support for IIO events. However, event
detection is not supported for all sensors, and if
userspace tries to configure accelerometer wakeup
events on a sensor device that does not support
them (e.g. LSM6DS0), st_lsm6dsx_write_event()
dereferences a NULL pointer when trying to write
to the wakeup register. Define an additional
struct iio_chan_spec array whose members have a
NULL event_spec field, and use this array instead
of st_lsm6dsx_acc_channels for sensors without
event detection capability. |
| CVE-2025-71199 |
In the Linux kernel, the
following vulnerability has been resolved: iio:
adc: at91-sama5d2_adc: Fix potential
use-after-free in sama5d2_adc driver
at91_adc_interrupt can call
at91_adc_touch_data_handler function to start the
work by schedule_work(&st->touch_st.workq).
If we remove the module which will call
at91_adc_remove to make cleanup, it will free
indio_dev through iio_device_unregister but quite
a bit later. While the work mentioned above will
be used. The sequence of operations that may lead
to a UAF bug is as follows: CPU0 CPU1 |
at91_adc_workq_handler at91_adc_remove |
iio_device_unregister(indio_dev) | //free
indio_dev a bit later | |
iio_push_to_buffers(indio_dev) | //use indio_dev
Fix it by ensuring that the work is canceled
before proceeding with the cleanup in
at91_adc_remove. |
| CVE-2025-71200 |
In the Linux kernel, the
following vulnerability has been resolved: mmc:
sdhci-of-dwcmshc: Prevent illegal clock reduction
in HS200/HS400 mode When operating in HS200 or
HS400 timing modes, reducing the clock frequency
below 52MHz will lead to link broken as the
Rockchip DWC MSHC controller requires maintaining
a minimum clock of 52MHz in these modes. Add a
check to prevent illegal clock reduction through
debugfs: root@debian:/# echo 50000000 >
/sys/kernel/debug/mmc0/clock root@debian:/# [
30.090146] mmc0: running CQE recovery mmc0: cqhci:
Failed to halt mmc0: cqhci: spurious TCN for tag 0
WARNING: drivers/mmc/host/cqhci-core.c:797 at
cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24
Modules linked in: CPU: 1 UID: 0 PID: 24 Comm:
kworker/1:0H Not tainted
6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT
Hardware name: Rockchip RK3588 EVB1 V10 Board (DT)
Workqueue: kblockd blk_mq_run_work_fn pstate:
604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS
BTYPE=--) pc : cqhci_irq+0x254/0x818 lr :
cqhci_irq+0x254/0x818 ... |
| CVE-2025-71220 |
In the Linux kernel, the
following vulnerability has been resolved:
smb/server: call ksmbd_session_rpc_close() on
error path in create_smb2_pipe() When
ksmbd_iov_pin_rsp() fails, we should call
ksmbd_session_rpc_close(). |
| CVE-2025-71222 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
wlcore: ensure skb headroom before skb_push This
avoids occasional skb_under_panic Oops from
wl1271_tx_work. In this case, headroom is less
than needed (typically 110 - 94 = 16
bytes). |
| CVE-2025-71224 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
mac80211: ocb: skip rx_no_sta when interface is
not joined ieee80211_ocb_rx_no_sta() assumes a
valid channel context, which is only present after
JOIN_OCB. RX may run before JOIN_OCB is executed,
in which case the OCB interface is not
operational. Skip RX peer handling when the
interface is not joined to avoid warnings in the
RX path. |
| CVE-2025-71225 |
In the Linux kernel, the
following vulnerability has been resolved: md:
suspend array while updating raid_disks via sysfs
In raid1_reshape(), freeze_array() is called
before modifying the r1bio memory pool
(conf->r1bio_pool) and conf->raid_disks, and
unfreeze_array() is called after the update is
completed. However, freeze_array() only waits
until nr_sync_pending and (nr_pending - nr_queued)
of all buckets reaches zero. When an I/O error
occurs, nr_queued is increased and the
corresponding r1bio is queued to either retry_list
or bio_end_io_list. As a result, freeze_array()
may unblock before these r1bios are released. This
can lead to a situation where conf->raid_disks
and the mempool have already been updated while
queued r1bios, allocated with the old raid_disks
value, are later released. Consequently,
free_r1bio() may access memory out of bounds in
put_all_bios() and release r1bios of the wrong
size to the new mempool, potentially causing
issues with the mempool as well. Since only normal
I/O might increase nr_queued while an I/O error
occurs, suspending the array avoids this issue.
Note: Updating raid_disks via ioctl SET_ARRAY_INFO
already suspends the array. Therefore, we suspend
the array when updating raid_disks via sysfs to
avoid this issue too. |
| CVE-2025-71268 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
fix reservation leak in some error paths when
inserting inline extent If we fail to allocate a
path or join a transaction, we return from
__cow_file_range_inline() without freeing the
reserved qgroup data, resulting in a leak. Fix
this by ensuring we call btrfs_qgroup_free_data()
in such cases. |
| CVE-2025-71299 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
cadence-quadspi: Parse DT for flashes with the
rest of the DT parsing The recent refactoring of
where runtime PM is enabled done in commit
f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm
runtime earlier to avoid imbalance") made the fact
that when we do a pm_runtime_disable() in the
error paths of probe() we can trigger a runtime
disable which in turn results in duplicate clock
disables. This is particularly likely to happen
when there is missing or broken DT description for
the flashes attached to the controller. Early on
in the probe function we do a
pm_runtime_get_noresume() since the probe function
leaves the device in a powered up state but in the
error path we can't assume that PM is enabled so
we also manually disable everything, including
clocks. This means that when runtime PM is active
both it and the probe function release the same
reference to the main clock for the IP, triggering
warnings from the clock subsystem: [ 8.693719]
clk:75:7 already disabled [ 8.693791] WARNING:
CPU: 1 PID: 185 at
/usr/src/kernel/drivers/clk/clk.c:1188
clk_core_disable+0xa0/0xb ... [ 8.694261]
clk_core_disable+0xa0/0xb4 (P) [ 8.694272]
clk_disable+0x38/0x60 [ 8.694283]
cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi] [
8.694309] platform_probe+0x5c/0xa4 Dealing with
this issue properly is complicated by the fact
that we don't know if runtime PM is active so
can't tell if it will disable the clocks or not.
We can, however, sidestep the issue for the flash
descriptions by moving their parsing to when we
parse the controller properties which also save us
doing a bunch of setup which can never be used so
let's do that. |
| CVE-2025-71300 |
In the Linux kernel, the
following vulnerability has been resolved: Revert
"arm64: zynqmp: Add an OP-TEE node to the device
tree" This reverts commit
06d22ed6b6635b17551f386b50bb5aaff9b75fbe. OP-TEE
logic in U-Boot automatically injects a
reserved-memory node along with optee firmware
node to kernel device tree. The injection logic is
dependent on that there is no manually defined
optee node. Having the node in zynqmp.dtsi
effectively breaks OP-TEE's insertion of the
reserved-memory node, causing memory access
violations during runtime. |
| CVE-2025-71302 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/panthor: fix for dma-fence safe access rules
Commit 506aa8b02a8d6 ("dma-fence: Add safe access
helpers and document the rules") details the
dma-fence safe access rules. The most common
culprit is that drm_sched_fence_get_timeline_name
may race with group_free_queue. |
| CVE-2025-71313 |
In the Linux kernel, the
following vulnerability has been resolved: PCI:
endpoint: Add missing NULL check for
alloc_workqueue() alloc_workqueue() can return
NULL on memory allocation failure. Without proper
error checking, this may lead to a NULL pointer
dereference when queue_work() is later called with
the NULL workqueue pointer in epf_ntb_epc_init().
Add a NULL check immediately after
alloc_workqueue() and return -ENOMEM on failure to
prevent the driver from loading with an invalid
workqueue pointer. |
| CVE-2025-71315 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/vkms: Convert to DRM's vblank timer Replace
vkms' vblank timer with the DRM implementation.
The DRM code is identical in concept, but differs
in implementation. Vblank timers are covered in
vblank helpers and initializer macros, so remove
the corresponding hrtimer in struct vkms_output.
The vblank timer calls vkms' custom timeout code
via handle_vblank_timeout in struct
drm_crtc_helper_funcs. |
| CVE-2026-0545 |
In mlflow/mlflow, the FastAPI
job endpoints under `/ajax-api/3.0/jobs/*` are not
protected by authentication or authorization when
the `basic-auth` app is enabled. This
vulnerability affects the latest version of the
repository. If job execution is enabled
(`MLFLOW_SERVER_ENABLE_JOB_EXECUTION=true`) and
any job function is allowlisted, any network
client can submit, read, search, and cancel jobs
without credentials, bypassing basic-auth
entirely. This can lead to unauthenticated remote
code execution if allowed jobs perform privileged
actions such as shell execution or filesystem
changes. Even if jobs are deemed safe, this still
constitutes an authentication bypass, potentially
resulting in job spam, denial of service (DoS), or
data exposure in job results. |
| CVE-2026-1839 |
A vulnerability in the
HuggingFace Transformers library, specifically in
the `Trainer` class, allows for arbitrary code
execution. The `_load_rng_state()` method in
`src/transformers/trainer.py` at line 3059 calls
`torch.load()` without the `weights_only=True`
parameter. This issue affects all versions of the
library supporting `torch>=2.2` when used with
PyTorch versions below 2.6, as the
`safe_globals()` context manager provides no
protection in these versions. An attacker can
exploit this vulnerability by supplying a
malicious checkpoint file, such as
`rng_state.pth`, which can execute arbitrary code
when loaded. The issue is resolved in version
v5.0.0rc3. |
| CVE-2026-2652 |
A vulnerability in
mlflow/mlflow versions 3.9.0 and earlier allows
unauthenticated access to certain FastAPI routes
when the server is started with authentication
enabled (`--app-name basic-auth`) and served via
uvicorn (ASGI). The FastAPI permission middleware
only enforces authentication on `/gateway/`
routes, leaving other routes such as the Job API
(`/ajax-api/3.0/jobs/*`) and the OpenTelemetry
trace ingestion API (`/v1/traces`) unprotected.
This allows unauthenticated remote attackers to
submit jobs, read job results, cancel running
jobs, and inject arbitrary trace data into
experiments. The issue arises from an
architectural mismatch between Flask and FastAPI
authentication mechanisms, where the
`_find_fastapi_validator()` function fails to
handle non-`/gateway/` paths, resulting in a
complete authentication bypass. This vulnerability
is fixed in version 3.10.0. |
| CVE-2026-4137 |
In mlflow/mlflow versions
prior to 3.11.0, the `get_or_create_nfs_tmp_dir()`
function in `mlflow/utils/file_utils.py` creates
temporary directories with world-writable
permissions (0o777), and the
`_create_model_downloading_tmp_dir()` function in
`mlflow/pyfunc/__init__.py` creates directories
with group-writable permissions (0o770). These
insecure permissions allow local attackers to
tamper with model artifacts, such as
cloudpickle-serialized Python objects, and achieve
arbitrary code execution when the tampered
artifacts are deserialized via
`cloudpickle.load()`. This vulnerability is
particularly critical in environments with shared
NFS mounts, such as Databricks, where NFS is
enabled by default. The issue is a continuation of
the vulnerability class addressed in
CVE-2025-10279, which was only partially
fixed. |
| CVE-2026-10118 |
A flaw was found in Poppler's
Splash backend. A remote attacker could exploit
this vulnerability by crafting a malicious PDF
file that, when rendered, triggers an integer
overflow in the `tilingPatternFill` function. This
overflow leads to an undersized heap memory
allocation, allowing a subsequent out-of-bounds
write. Successful exploitation could result in
arbitrary code execution, information disclosure,
or denial of service within the context of the
application processing the PDF. |
| CVE-2026-21226 |
Deserialization of untrusted
data in Azure Core shared client library for
Python allows an authorized attacker to execute
code over a network. |
| CVE-2026-21726 |
The CVE-2021-36156 fix
validates the namespace parameter for path
traversal sequences after a single URL decode, by
double encoding, an attacker can read files at the
Ruler API endpoint /loki/api/v1/rules/{namespace}
Thanks to Prasanth Sundararajan for reporting this
vulnerability. |
| CVE-2026-21998 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Optimizer). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Easily exploitable vulnerability allows high
privileged attacker with network access via
multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 4.9
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-22001 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Information Schema). Supported versions that are
affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and
9.0.0-9.6.0. Easily exploitable vulnerability
allows high privileged attacker with network
access via multiple protocols to compromise MySQL
Server. Successful attacks of this vulnerability
can result in unauthorized read access to a subset
of MySQL Server accessible data. CVSS 3.1 Base
Score 2.7 (Confidentiality impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N). |
| CVE-2026-22002 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Optimizer). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Easily exploitable vulnerability allows high
privileged attacker with network access via
multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 4.9
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-22004 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component:
InnoDB). Supported versions that are affected are
8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily
exploitable vulnerability allows high privileged
attacker with network access via multiple
protocols to compromise MySQL Server. Successful
attacks of this vulnerability can result in
unauthorized ability to cause a hang or frequently
repeatable crash (complete DOS) of MySQL Server.
CVSS 3.1 Base Score 4.9 (Availability impacts).
CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-22005 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Optimizer). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Easily exploitable vulnerability allows high
privileged attacker with network access via
multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 4.9
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-22009 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Optimizer). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Easily exploitable vulnerability allows low
privileged attacker with network access via
multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 6.5
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-22015 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Information Schema). Supported versions that are
affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and
9.0.0-9.6.0. Easily exploitable vulnerability
allows low privileged attacker with network access
via multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized read access to a subset of
MySQL Server accessible data. CVSS 3.1 Base Score
4.3 (Confidentiality impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N). |
| CVE-2026-22017 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Optimizer). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Easily exploitable vulnerability allows low
privileged attacker with network access via
multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 6.5
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-22690 |
pypdf is a free and
open-source pure-python PDF library. Prior to
version 6.6.0, pypdf has possible long runtimes
for missing /Root object with large /Size values.
An attacker who uses this vulnerability can craft
a PDF which leads to possibly long runtimes for
actually invalid files. This can be achieved by
omitting the /Root entry in the trailer, while
using a rather large /Size value. Only the
non-strict reading mode is affected. This issue
has been patched in version 6.6.0. |
| CVE-2026-22691 |
pypdf is a free and
open-source pure-python PDF library. Prior to
version 6.6.0, pypdf has possible long runtimes
for malformed startxref. An attacker who uses this
vulnerability can craft a PDF which leads to
possibly long runtimes for invalid startxref
entries. When rebuilding the cross-reference
table, PDF files with lots of whitespace
characters become problematic. Only the non-strict
reading mode is affected. Only the non-strict
reading mode is affected. This issue has been
patched in version 6.6.0. |
| CVE-2026-22976 |
In the Linux kernel, the
following vulnerability has been resolved:
net/sched: sch_qfq: Fix NULL deref when
deactivating inactive aggregate in qfq_reset
`qfq_class->leaf_qdisc->q.qlen > 0` does
not imply that the class itself is active. Two
qfq_class objects may point to the same
leaf_qdisc. This happens when: 1. one QFQ qdisc is
attached to the dev as the root qdisc, and 2.
another QFQ qdisc is temporarily referenced (e.g.,
via qdisc_get() / qdisc_put()) and is pending to
be destroyed, as in function tc_new_tfilter. When
packets are enqueued through the root QFQ qdisc,
the shared leaf_qdisc->q.qlen increases. At the
same time, the second QFQ qdisc triggers qdisc_put
and qdisc_destroy: the qdisc enters qfq_reset()
with its own q->q.qlen == 0, but its class's
leaf qdisc->q.qlen > 0. Therefore, the
qfq_reset would wrongly deactivate an inactive
aggregate and trigger a null-deref in
qfq_deactivate_agg: [ 0.903172] BUG: kernel NULL
pointer dereference, address: 0000000000000000 [
0.903571] #PF: supervisor write access in kernel
mode [ 0.903860] #PF: error_code(0x0002) -
not-present page [ 0.904177] PGD 10299b067 P4D
10299b067 PUD 10299c067 PMD 0 [ 0.904502] Oops:
Oops: 0002 [#1] SMP NOPTI [ 0.904737] CPU: 0 UID:
0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+
#2 NONE [ 0.905157] Hardware name: QEMU Standard
PC (i440FX + PIIX, 1996), BIOS
rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org
04/01/2014 [ 0.905754] RIP:
0010:qfq_deactivate_agg (include/linux/list.h:992
(discriminator 2) include/linux/list.h:1006
(discriminator 2) net/sched/sch_qfq.c:1367
(discriminator 2) net/sched/sch_qfq.c:1393
(discriminator 2)) [ 0.906046] Code: 0f 84 4d 01
00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48
8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3
ea 8b 4b 18 0 Code starting with the faulting
instruction
=========================================== 0: 0f
84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov
%rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d:
48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx
14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2
shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b
13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi
24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov
0x18(%rbx),%ecx ... [ 0.907095] RSP:
0018:ffffc900004a39a0 EFLAGS: 00010246 [ 0.907368]
RAX: ffff8881043a0880 RBX: ffff888102953340 RCX:
0000000000000000 [ 0.907723] RDX: 0000000000000000
RSI: 0000000000000000 RDI: 0000000000000000 [
0.908100] RBP: ffff888102952180 R08:
0000000000000000 R09: 0000000000000000 [ 0.908451]
R10: ffff8881043a0000 R11: 0000000000000000 R12:
ffff888102952000 [ 0.908804] R13: ffff888102952180
R14: ffff8881043a0ad8 R15: ffff8881043a0880 [
0.909179] FS: 000000002a1a0380(0000)
GS:ffff888196d8d000(0000) knlGS:0000000000000000 [
0.909572] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 [ 0.909857] CR2: 0000000000000000
CR3: 0000000102993002 CR4: 0000000000772ef0 [
0.910247] PKRU: 55555554 [ 0.910391] Call Trace: [
0.910527] <TASK> [ 0.910638] qfq_reset_qdisc
(net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)
[ 0.910826] qdisc_reset
(include/linux/skbuff.h:2195
include/linux/skbuff.h:2501
include/linux/skbuff.h:3424
include/linux/skbuff.h:3430
net/sched/sch_generic.c:1036) [ 0.911040]
__qdisc_destroy (net/sched/sch_generic.c:1076) [
0.911236] tc_new_tfilter
(net/sched/cls_api.c:2447) [ 0.911447]
rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) [
0.911663] ? __pfx_rtnetlink_rcv_msg
(net/core/rtnetlink.c:6861) [ 0.911894]
netlink_rcv_skb (net/netlink/af_netlink.c:2550) [
0.912100] netlink_unicast
(net/netlink/af_netlink.c:1319
net/netlink/af_netlink.c:1344) [ 0.912296] ?
__alloc_skb (net/core/skbuff.c:706) [ 0.912484]
netlink_sendmsg (net/netlink/af
---truncated--- |
| CVE-2026-22977 |
In the Linux kernel, the
following vulnerability has been resolved: net:
sock: fix hardened usercopy panic in
sock_recv_errqueue skbuff_fclone_cache was created
without defining a usercopy region, [1] unlike
skbuff_head_cache which properly whitelists the
cb[] field. [2] This causes a usercopy BUG() when
CONFIG_HARDENED_USERCOPY is enabled and the kernel
attempts to copy sk_buff.cb data to userspace via
sock_recv_errqueue() -> put_cmsg(). The crash
occurs when: 1. TCP allocates an skb using
alloc_skb_fclone() (from skbuff_fclone_cache) [1]
2. The skb is cloned via skb_clone() using the
pre-allocated fclone [3] 3. The cloned skb is
queued to sk_error_queue for timestamp reporting
4. Userspace reads the error queue via
recvmsg(MSG_ERRQUEUE) 5. sock_recv_errqueue()
calls put_cmsg() to copy serr->ee from
skb->cb [4] 6. __check_heap_object() fails
because skbuff_fclone_cache has no usercopy
whitelist [5] When cloned skbs allocated from
skbuff_fclone_cache are used in the socket error
queue, accessing the sock_exterr_skb structure in
skb->cb via put_cmsg() triggers a usercopy
hardening violation: [ 5.379589] usercopy: Kernel
memory exposure attempt detected from SLUB object
'skbuff_fclone_cache' (offset 296, size 16)! [
5.382796] kernel BUG at mm/usercopy.c:102! [
5.383923] Oops: invalid opcode: 0000 [#1] SMP
KASAN NOPTI [ 5.384903] CPU: 1 UID: 0 PID: 138
Comm: poc_put_cmsg Not tainted 6.12.57 #7 [
5.384903] Hardware name: QEMU Standard PC (i440FX
+ PIIX, 1996), BIOS
rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org
04/01/2014 [ 5.384903] RIP:
0010:usercopy_abort+0x6c/0x80 [ 5.384903] Code: 1a
86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a
86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f
45 f3 e8 84 27 88 ff <0f> 0b 490 [ 5.384903]
RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246 [
5.384903] RAX: 000000000000006f RBX:
ffff88800f0ad2a8 RCX: 1ffffffff0f72e74 [ 5.384903]
RDX: 0000000000000000 RSI: 0000000000000004 RDI:
ffffffff87b973a0 [ 5.384903] RBP: 0000000000000010
R08: 0000000000000000 R09: fffffbfff0f72e74 [
5.384903] R10: 0000000000000003 R11:
79706f6372657375 R12: 0000000000000001 [ 5.384903]
R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15:
ffffea00003c2b00 [ 5.384903] FS:
0000000011bc4380(0000) GS:ffff8880bf100000(0000)
knlGS:0000000000000000 [ 5.384903] CS: 0010 DS:
0000 ES: 0000 CR0: 0000000080050033 [ 5.384903]
CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4:
0000000000770ef0 [ 5.384903] PKRU: 55555554 [
5.384903] Call Trace: [ 5.384903] <TASK> [
5.384903] __check_heap_object+0x9a/0xd0 [
5.384903] __check_object_size+0x46c/0x690 [
5.384903] put_cmsg+0x129/0x5e0 [ 5.384903]
sock_recv_errqueue+0x22f/0x380 [ 5.384903]
tls_sw_recvmsg+0x7ed/0x1960 [ 5.384903] ?
srso_alias_return_thunk+0x5/0xfbef5 [ 5.384903] ?
schedule+0x6d/0x270 [ 5.384903] ?
srso_alias_return_thunk+0x5/0xfbef5 [ 5.384903] ?
mutex_unlock+0x81/0xd0 [ 5.384903] ?
__pfx_mutex_unlock+0x10/0x10 [ 5.384903] ?
__pfx_tls_sw_recvmsg+0x10/0x10 [ 5.384903] ?
_raw_spin_lock_irqsave+0x8f/0xf0 [ 5.384903] ?
_raw_read_unlock_irqrestore+0x20/0x40 [ 5.384903]
? srso_alias_return_thunk+0x5/0xfbef5 The crash
offset 296 corresponds to skb2->cb within
skbuff_fclones: - sizeof(struct sk_buff) = 232 -
offsetof(struct sk_buff, cb) = 40 - offset of
skb2.cb in fclones = 232 + 40 = 272 - crash offset
296 = 272 + 24 (inside sock_exterr_skb.ee) This
patch uses a local stack variable as a bounce
buffer to avoid the hardened usercopy check
failure. [1]
https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885
[2]
https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104
[3]
https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566
[4]
https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491
[5]
https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719 |
| CVE-2026-22978 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
avoid kernel-infoleak from struct iw_point struct
iw_point has a 32bit hole on 64bit arches. struct
iw_point { void __user *pointer; /* Pointer to the
data (in user space) */ __u16 length; /* number of
fields or size in bytes */ __u16 flags; /*
Optional params */ }; Make sure to zero the
structure to avoid disclosing 32bits of kernel
data to user space. |
| CVE-2026-22979 |
In the Linux kernel, the
following vulnerability has been resolved: net:
fix memory leak in skb_segment_list for GRO
packets When skb_segment_list() is called during
packet forwarding, it handles packets that were
aggregated by the GRO engine. Historically, the
segmentation logic in skb_segment_list assumes
that individual segments are split from a parent
SKB and may need to carry their own socket memory
accounting. Accordingly, the code transfers
truesize from the parent to the newly created
segments. Prior to commit ed4cccef64c1 ("gro: fix
ownership transfer"), this truesize subtraction in
skb_segment_list() was valid because fragments
still carry a reference to the original socket.
However, commit ed4cccef64c1 ("gro: fix ownership
transfer") changed this behavior by ensuring that
fraglist entries are explicitly orphaned
(skb->sk = NULL) to prevent illegal orphaning
later in the stack. This change meant that the
entire socket memory charge remained with the head
SKB, but the corresponding accounting logic in
skb_segment_list() was never updated. As a result,
the current code unconditionally adds each
fragment's truesize to delta_truesize and
subtracts it from the parent SKB. Since the
fragments are no longer charged to the socket,
this subtraction results in an effective
under-count of memory when the head is freed. This
causes sk_wmem_alloc to remain non-zero,
preventing socket destruction and leading to a
persistent memory leak. The leak can be observed
via KMEMLEAK when tearing down the networking
environment: unreferenced object
0xffff8881e6eb9100 (size 2048): comm "ping", pid
6720, jiffies 4295492526 backtrace:
kmem_cache_alloc_noprof+0x5c6/0x800
sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00
inet6_create.part.0+0x303/0x10d0
__sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0
Since skb_segment_list() is exclusively used for
SKB_GSO_FRAGLIST packets constructed by GRO, the
truesize adjustment is removed. The call to
skb_release_head_state() must be preserved. As
documented in commit cf673ed0e057 ("net: fix
fraglist segmentation reference count leak"), it
is still required to correctly drop references to
SKB extensions that may be overwritten during
__copy_skb_header(). |
| CVE-2026-22980 |
In the Linux kernel, the
following vulnerability has been resolved: nfsd:
provide locking for v4_end_grace Writing to
v4_end_grace can race with server shutdown and
result in memory being accessed after it was freed
- reclaim_str_hashtbl in particularly. We cannot
hold nfsd_mutex across the nfsd4_end_grace() call
as that is held while
client_tracking_op->init() is called and that
can wait for an upcall to nfsdcltrack which can
write to v4_end_grace, resulting in a deadlock.
nfsd4_end_grace() is also called by the landromat
work queue and this doesn't require locking as
server shutdown will stop the work and wait for it
before freeing anything that nfsd4_end_grace()
might access. However, we must be sure that
writing to v4_end_grace doesn't restart the work
item after shutdown has already waited for it. For
this we add a new flag protected with
nn->client_lock. It is set only while it is
safe to make client tracking calls, and
v4_end_grace only schedules work while the flag is
set with the spinlock held. So this patch adds a
nfsd_net field "client_tracking_active" which is
set as described. Another field
"grace_end_forced", is set when v4_end_grace is
written. After this is set, and providing
client_tracking_active is set, the laundromat is
scheduled. This "grace_end_forced" field bypasses
other checks for whether the grace period has
finished. This resolves a race which can result in
use-after-free. |
| CVE-2026-22982 |
In the Linux kernel, the
following vulnerability has been resolved: net:
mscc: ocelot: Fix crash when adding interface
under a lag Commit 15faa1f67ab4 ("lan966x: Fix
crash when adding interface under a lag") fixed a
similar issue in the lan966x driver caused by a
NULL pointer dereference. The
ocelot_set_aggr_pgids() function in the ocelot
driver has similar logic and is susceptible to the
same crash. This issue specifically affects the
ocelot_vsc7514.c frontend, which leaves unused
ports as NULL pointers. The felix_vsc9959.c
frontend is unaffected as it uses the DSA
framework which registers all ports. Fix this by
checking if the port pointer is valid before
accessing it. |
| CVE-2026-22984 |
In the Linux kernel, the
following vulnerability has been resolved:
libceph: prevent potential out-of-bounds reads in
handle_auth_done() Perform an explicit bounds
check on payload_len to avoid a possible
out-of-bounds access in the callout. [ idryomov:
changelog ] |
| CVE-2026-22990 |
In the Linux kernel, the
following vulnerability has been resolved:
libceph: replace overzealous BUG_ON in
osdmap_apply_incremental() If the osdmap is
(maliciously) corrupted such that the incremental
osdmap epoch is different from what is expected,
there is no need to BUG. Instead, just declare the
incremental osdmap to be invalid. |
| CVE-2026-22991 |
In the Linux kernel, the
following vulnerability has been resolved:
libceph: make free_choose_arg_map() resilient to
partial allocation free_choose_arg_map() may
dereference a NULL pointer if its caller fails
after a partial allocation. For example, in
decode_choose_args(), if allocation of
arg_map->args fails, execution jumps to the
fail label and free_choose_arg_map() is called.
Since arg_map->size is updated to a non-zero
value before memory allocation,
free_choose_arg_map() will iterate over
arg_map->args and dereference a NULL pointer.
To prevent this potential NULL pointer dereference
and make free_choose_arg_map() more resilient, add
checks for pointers before iterating. |
| CVE-2026-22992 |
In the Linux kernel, the
following vulnerability has been resolved:
libceph: return the handler error from
mon_handle_auth_done() Currently any error from
ceph_auth_handle_reply_done() is propagated via
finish_auth() but isn't returned from
mon_handle_auth_done(). This results in higher
layers learning that (despite the monitor
considering us to be successfully authenticated)
something went wrong in the authentication phase
and reacting accordingly, but msgr2 still trying
to proceed with establishing the session in the
background. In the case of secure mode this can
trigger a WARN in setup_crypto() and later lead to
a NULL pointer dereference inside of
prepare_auth_signature(). |
| CVE-2026-22994 |
In the Linux kernel, the
following vulnerability has been resolved: bpf:
Fix reference count leak in
bpf_prog_test_run_xdp() syzbot is reporting
unregister_netdevice: waiting for sit0 to become
free. Usage count = 2 problem. A debug printk()
patch found that a refcount is obtained at
xdp_convert_md_to_buff() from
bpf_prog_test_run_xdp(). According to commit
ec94670fcb3b ("bpf: Support specifying ingress via
xdp_md context in BPF_PROG_TEST_RUN"), the
refcount obtained by xdp_convert_md_to_buff() will
be released by xdp_convert_buff_to_md().
Therefore, we can consider that the error handling
path introduced by commit 1c1949982524 ("bpf:
introduce frags support to
bpf_prog_test_run_xdp()") forgot to call
xdp_convert_buff_to_md(). |
| CVE-2026-22996 |
In the Linux kernel, the
following vulnerability has been resolved:
net/mlx5e: Don't store mlx5e_priv in mlx5e_dev
devlink priv mlx5e_priv is an unstable structure
that can be memset(0) if profile attaching fails,
mlx5e_priv in mlx5e_dev devlink private is used to
reference the netdev and mdev associated with that
struct. Instead, store netdev directly into
mlx5e_dev and get mdev from the containing
mlx5_adev aux device structure. This fixes a
kernel oops in mlx5e_remove when switchdev mode
fails due to change profile failure. $ devlink dev
eswitch set pci/0000:00:03.0 mode switchdev Error:
mlx5_core: Failed setting eswitch to offloads.
dmesg: workqueue: Failed to create a rescuer
kthread for wq "mlx5e": -EINTR mlx5_core
0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid
37199): mlx5e_priv_init failed, err=-12 mlx5_core
0012:03:00.1 gpu3rdma1:
mlx5e_netdev_change_profile: new profile init
failed, -12 workqueue: Failed to create a rescuer
kthread for wq "mlx5e": -EINTR mlx5_core
0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid
37199): mlx5e_priv_init failed, err=-12 mlx5_core
0012:03:00.1 gpu3rdma1:
mlx5e_netdev_change_profile: failed to rollback to
orig profile, -12 $ devlink dev reload
pci/0000:00:03.0 ==> oops BUG: kernel NULL
pointer dereference, address: 0000000000000520
#PF: supervisor read access in kernel mode #PF:
error_code(0x0000) - not-present page PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID:
521 Comm: devlink Not tainted 6.18.0-rc5+ #117
PREEMPT(voluntary) Hardware name: QEMU Standard PC
(Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:mlx5e_remove+0x68/0x130 RSP:
0018:ffffc900034838f0 EFLAGS: 00010246 RAX:
ffff88810283c380 RBX: ffff888101874400 RCX:
ffffffff826ffc45 RDX: 0000000000000000 RSI:
0000000000000001 RDI: 0000000000000000 RBP:
ffff888102d789c0 R08: ffff8881007137f0 R09:
ffff888100264e10 R10: ffffc90003483898 R11:
ffffc900034838a0 R12: ffff888100d261a0 R13:
ffff888100d261a0 R14: ffff8881018749a0 R15:
ffff888101874400 FS: 00007f8565fea740(0000)
GS:ffff88856a759000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000520 CR3: 000000010b11a004 CR4:
0000000000370ef0 Call Trace: <TASK>
device_release_driver_internal+0x19c/0x200
bus_remove_device+0xc6/0x130
device_del+0x160/0x3d0 ?
devl_param_driverinit_value_get+0x2d/0x90
mlx5_detach_device+0x89/0xe0
mlx5_unload_one_devl_locked+0x3a/0x70
mlx5_devlink_reload_down+0xc8/0x220
devlink_reload+0x7d/0x260
devlink_nl_reload_doit+0x45b/0x5a0
genl_family_rcv_msg_doit+0xe8/0x140 |
| CVE-2026-22997 |
In the Linux kernel, the
following vulnerability has been resolved: net:
can: j1939: j1939_xtp_rx_rts_session_active():
deactivate session upon receiving the second rts
Since j1939_session_deactivate_activate_next() in
j1939_tp_rxtimer() is called only when the timer
is enabled, we need to call
j1939_session_deactivate_activate_next() if we
cancelled the timer. Otherwise, refcount for
j1939_session leaks, which will later appear as |
unregister_netdevice: waiting for vcan0 to become
free. Usage count = 2. problem. |
| CVE-2026-22998 |
In the Linux kernel, the
following vulnerability has been resolved:
nvme-tcp: fix NULL pointer dereferences in
nvmet_tcp_build_pdu_iovec Commit efa56305908b
("nvmet-tcp: Fix a kernel panic when host sends an
invalid H2C PDU length") added ttag bounds
checking and data_offset validation in
nvmet_tcp_handle_h2c_data_pdu(), but it did not
validate whether the command's data structures
(cmd->req.sg and cmd->iov) have been
properly initialized before processing H2C_DATA
PDUs. The nvmet_tcp_build_pdu_iovec() function
dereferences these pointers without NULL checks.
This can be triggered by sending H2C_DATA PDU
immediately after the ICREQ/ICRESP handshake,
before sending a CONNECT command or NVMe write
command. Attack vectors that trigger NULL pointer
dereferences: 1. H2C_DATA PDU sent before CONNECT
→ both pointers NULL 2. H2C_DATA PDU for READ
command → cmd->req.sg allocated, cmd->iov
NULL 3. H2C_DATA PDU for uninitialized command
slot → both pointers NULL The fix validates both
cmd->req.sg and cmd->iov before calling
nvmet_tcp_build_pdu_iovec(). Both checks are
required because: - Uninitialized commands: both
NULL - READ commands: cmd->req.sg allocated,
cmd->iov NULL - WRITE commands: both
allocated |
| CVE-2026-22999 |
In the Linux kernel, the
following vulnerability has been resolved:
net/sched: sch_qfq: do not free existing class in
qfq_change_class() Fixes qfq_change_class() error
case. cl->qdisc and cl should only be freed if
a new class and qdisc were allocated, or we risk
various UAF. |
| CVE-2026-23000 |
In the Linux kernel, the
following vulnerability has been resolved:
net/mlx5e: Fix crash on profile change rollback
failure mlx5e_netdev_change_profile can fail to
attach a new profile and can fail to rollback to
old profile, in such case, we could end up with a
dangling netdev with a fully reset netdev_priv. A
retry to change profile, e.g. another attempt to
call mlx5e_netdev_change_profile via switchdev
mode change, will crash trying to access the now
NULL priv->mdev. This fix allows
mlx5e_netdev_change_profile() to handle previous
failures and an empty priv, by not assuming priv
is valid. Pass netdev and mdev to all flows
requiring mlx5e_netdev_change_profile() and avoid
passing priv. In mlx5e_netdev_change_profile()
check if current priv is valid, and if not, just
attach the new profile without trying to access
the old one. This fixes the following oops, when
enabling switchdev mode for the 2nd time after
first time failure: ## Enabling switchdev mode
first time: mlx5_core 0012:03:00.1: E-Switch:
Supported tc chains and prios offload workqueue:
Failed to create a rescuer kthread for wq "mlx5e":
-EINTR mlx5_core 0012:03:00.1:
mlx5e_netdev_init_profile:6214:(pid 37199):
mlx5e_priv_init failed, err=-12 mlx5_core
0012:03:00.1 gpu3rdma1:
mlx5e_netdev_change_profile: new profile init
failed, -12 workqueue: Failed to create a rescuer
kthread for wq "mlx5e": -EINTR mlx5_core
0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid
37199): mlx5e_priv_init failed, err=-12 mlx5_core
0012:03:00.1 gpu3rdma1:
mlx5e_netdev_change_profile: failed to rollback to
orig profile, -12 ^^^^^^^^ mlx5_core 0000:00:03.0:
E-Switch: Disable: mode(LEGACY), nvfs(0),
necvfs(0), active vports(0) ## retry: Enabling
switchdev mode 2nd time: mlx5_core 0000:00:03.0:
E-Switch: Supported tc chains and prios offload
BUG: kernel NULL pointer dereference, address:
0000000000000038 #PF: supervisor read access in
kernel mode #PF: error_code(0x0000) - not-present
page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted
6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name:
QEMU Standard PC (Q35 + ICH9, 2009), BIOS
1.16.3-2.fc40 04/01/2014 RIP:
0010:mlx5e_detach_netdev+0x3c/0x90 Code: 50 00 00
f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16
48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6
e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08
48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP:
0018:ffffc90000673890 EFLAGS: 00010246 RAX:
0000000000000000 RBX: ffff8881036a89c0 RCX:
0000000000000000 RDX: ffff888113f63800 RSI:
ffffffff822fe720 RDI: 0000000000000000 RBP:
0000000000000000 R08: 0000000000002dcd R09:
0000000000000000 R10: ffffc900006738e8 R11:
00000000ffffffff R12: 0000000000000000 R13:
0000000000000000 R14: ffff8881036a89c0 R15:
0000000000000000 FS: 00007fdfb8384740(0000)
GS:ffff88856a9d6000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000038 CR3: 0000000112ae0005 CR4:
0000000000370ef0 Call Trace: <TASK>
mlx5e_netdev_change_profile+0x45/0xb0
mlx5e_vport_rep_load+0x27b/0x2d0
mlx5_esw_offloads_rep_load+0x72/0xf0
esw_offloads_enable+0x5d0/0x970
mlx5_eswitch_enable_locked+0x349/0x430 ?
is_mp_supported+0x57/0xb0
mlx5_devlink_eswitch_mode_set+0x26b/0x430
devlink_nl_eswitch_set_doit+0x6f/0xf0
genl_family_rcv_msg_doit+0xe8/0x140
genl_rcv_msg+0x18b/0x290 ?
__pfx_devlink_nl_pre_doit+0x10/0x10 ?
__pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ?
__pfx_devlink_nl_post_doit+0x10/0x10 ?
__pfx_genl_rcv_msg+0x10/0x10
netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40
netlink_unicast+0x282/0x3e0 ?
__alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430
__sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x50/0x1f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP:
0033:0x7fdfb8495047 |
| CVE-2026-23001 |
In the Linux kernel, the
following vulnerability has been resolved:
macvlan: fix possible UAF in
macvlan_forward_source() Add RCU protection on
(struct macvlan_source_entry)->vlan. Whenever
macvlan_hash_del_source() is called, we must clear
entry->vlan pointer before RCU grace period
starts. This allows macvlan_forward_source() to
skip over entries queued for freeing. Note that
macvlan_dev are already RCU protected, as they are
embedded in a standard netdev (netdev_priv(ndev)).
https:
//lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u |
| CVE-2026-23003 |
In the Linux kernel, the
following vulnerability has been resolved:
ip6_tunnel: use skb_vlan_inet_prepare() in
__ip6_tnl_rcv() Blamed commit did not take care of
VLAN encapsulations as spotted by syzbot [1]. Use
skb_vlan_inet_prepare() instead of
pskb_inet_may_pull(). [1] BUG: KMSAN: uninit-value
in __INET_ECN_decapsulate
include/net/inet_ecn.h:253 [inline] BUG: KMSAN:
uninit-value in INET_ECN_decapsulate
include/net/inet_ecn.h:275 [inline] BUG: KMSAN:
uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0
include/net/inet_ecn.h:321 __INET_ECN_decapsulate
include/net/inet_ecn.h:253 [inline]
INET_ECN_decapsulate include/net/inet_ecn.h:275
[inline] IP6_ECN_decapsulate+0x7a8/0x1fa0
include/net/inet_ecn.h:321
ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0
net/ipv6/ip6_tunnel.c:729
__ip6_tnl_rcv+0xed9/0x1b50
net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100
net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90
net/ipv6/ip6_gre.c:-1
ip6_protocol_deliver_rcu+0x1c89/0x2c60
net/ipv6/ip6_input.c:438
ip6_input_finish+0x1f4/0x4a0
net/ipv6/ip6_input.c:489 NF_HOOK
include/linux/netfilter.h:318 [inline]
ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500
ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590
dst_input include/net/dst.h:474 [inline]
ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79
NF_HOOK include/linux/netfilter.h:318 [inline]
ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311
__netif_receive_skb_one_core net/core/dev.c:6139
[inline] __netif_receive_skb+0x1df/0xac0
net/core/dev.c:6252 netif_receive_skb_internal
net/core/dev.c:6338 [inline]
netif_receive_skb+0x57/0x630 net/core/dev.c:6397
tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485
tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953
tun_chr_write_iter+0x3e9/0x5c0
drivers/net/tun.c:1999 new_sync_write
fs/read_write.c:593 [inline]
vfs_write+0xbe2/0x15d0 fs/read_write.c:686
ksys_write fs/read_write.c:738 [inline]
__do_sys_write fs/read_write.c:749 [inline]
__se_sys_write fs/read_write.c:746 [inline]
__x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746
x64_sys_call+0x30ab/0x3e70
arch/x86/include/generated/asm/syscalls_64.h:2
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xd3/0xf80
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit
was created at: slab_post_alloc_hook
mm/slub.c:4960 [inline] slab_alloc_node
mm/slub.c:5263 [inline]
kmem_cache_alloc_node_noprof+0x9e7/0x17a0
mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0
net/core/skbuff.c:586 __alloc_skb+0x805/0x1040
net/core/skbuff.c:690 alloc_skb
include/linux/skbuff.h:1383 [inline]
alloc_skb_with_frags+0xc5/0xa60
net/core/skbuff.c:6712
sock_alloc_send_pskb+0xacc/0xc60
net/core/sock.c:2995 tun_alloc_skb
drivers/net/tun.c:1461 [inline]
tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794
tun_chr_write_iter+0x3e9/0x5c0
drivers/net/tun.c:1999 new_sync_write
fs/read_write.c:593 [inline]
vfs_write+0xbe2/0x15d0 fs/read_write.c:686
ksys_write fs/read_write.c:738 [inline]
__do_sys_write fs/read_write.c:749 [inline]
__se_sys_write fs/read_write.c:746 [inline]
__x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746
x64_sys_call+0x30ab/0x3e70
arch/x86/include/generated/asm/syscalls_64.h:2
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xd3/0xf80
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0
UID: 0 PID: 6465 Comm: syz.0.17 Not tainted
syzkaller #0 PREEMPT(none) Hardware name: Google
Google Compute Engine/Google Compute Engine, BIOS
Google 10/25/2025 |
| CVE-2026-23005 |
In the Linux kernel, the
following vulnerability has been resolved:
x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state
whenever XFD[i]=1 When loading guest XSAVE state
via KVM_SET_XSAVE, and when updating XFD in
response to a guest WRMSR, clear XFD-disabled
features in the saved (or to be restored)
XSTATE_BV to ensure KVM doesn't attempt to load
state for features that are disabled via the
guest's XFD. Because the kernel executes XRSTOR
with the guest's XFD, saving XSTATE_BV[i]=1 with
XFD[i]=1 will cause XRSTOR to #NM and panic the
kernel. E.g. if fpu_update_guest_xfd() sets XFD
without clearing XSTATE_BV: ------------[ cut here
]------------ WARNING:
arch/x86/kernel/traps.c:1524 at
exc_device_not_available+0x101/0x110, CPU#29:
amx_test/848 Modules linked in: kvm_intel kvm
irqbypass CPU: 29 UID: 1000 PID: 848 Comm:
amx_test Not tainted
6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm
#171 NONE Hardware name: QEMU Standard PC (Q35 +
ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP:
0010:exc_device_not_available+0x101/0x110 Call
Trace: <TASK>
asm_exc_device_not_available+0x1a/0x20 RIP:
0010:restore_fpregs_from_fpstate+0x36/0x90
switch_fpu_return+0x4a/0xb0
kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]
kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]
__x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK> ---[ end trace 0000000000000000 ]---
This can happen if the guest executes
WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and a host
IRQ triggers kernel_fpu_begin() prior to the
vmexit handler's call to fpu_update_guest_xfd().
and if userspace stuffs XSTATE_BV[i]=1 via
KVM_SET_XSAVE: ------------[ cut here
]------------ WARNING:
arch/x86/kernel/traps.c:1524 at
exc_device_not_available+0x101/0x110, CPU#14:
amx_test/867 Modules linked in: kvm_intel kvm
irqbypass CPU: 14 UID: 1000 PID: 867 Comm:
amx_test Not tainted
6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm
#168 NONE Hardware name: QEMU Standard PC (Q35 +
ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP:
0010:exc_device_not_available+0x101/0x110 Call
Trace: <TASK>
asm_exc_device_not_available+0x1a/0x20 RIP:
0010:restore_fpregs_from_fpstate+0x36/0x90
fpu_swap_kvm_fpstate+0x6b/0x120
kvm_load_guest_fpu+0x30/0x80 [kvm]
kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]
kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]
__x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK> ---[ end trace 0000000000000000 ]---
The new behavior is consistent with the AMX
architecture. Per Intel's SDM, XSAVE saves
XSTATE_BV as '0' for components that are disabled
via XFD (and non-compacted XSAVE saves the initial
configuration of the state component): If XSAVE,
XSAVEC, XSAVEOPT, or XSAVES is saving the state
component i, the instruction does not generate #NM
when XCR0[i] = IA32_XFD[i] = 1; instead, it
operates as if XINUSE[i] = 0 (and the state
component was in its initial state): it saves bit
i of XSTATE_BV field of the XSAVE header as 0; in
addition, XSAVE saves the initial configuration of
the state component (the other instructions do not
save state component i). Alternatively, KVM could
always do XRSTOR with XFD=0, e.g. by using a
constant XFD based on the set of enabled features
when XSAVEing for a struct fpu_guest. However,
having XSTATE_BV[i]=1 for XFD-disabled features
can only happen in the above interrupt case, or in
similar scenarios involving preemption on
preemptible kernels, because
fpu_swap_kvm_fpstate()'s call to
save_fpregs_to_fpstate() saves the outgoing FPU
state with the current XFD; and that is (on all
but the first WRMSR to XFD) the guest XFD.
Therefore, XFD can only go out of sync with
XSTATE_BV in the above interrupt case, or in
similar scenarios involving preemption on
preemptible kernels, and it we can consider it (de
facto) part of KVM ABI that KVM_GET_XSAVE returns
XSTATE_BV[i]=0 for XFD-disabled features. [Move
clea ---truncated--- |
| CVE-2026-23006 |
In the Linux kernel, the
following vulnerability has been resolved: ASoC:
tlv320adcx140: fix null pointer The
"snd_soc_component" in "adcx140_priv" was only
used once but never set. It was only used for
reaching "dev" which is already present in
"adcx140_priv". |
| CVE-2026-23010 |
In the Linux kernel, the
following vulnerability has been resolved: ipv6:
Fix use-after-free in inet6_addr_del(). syzbot
reported use-after-free of inet6_ifaddr in
inet6_addr_del(). [0] The cited commit
accidentally moved ipv6_del_addr() for mngtmpaddr
before reading its ifp->flags for temporary
addresses in inet6_addr_del(). Let's move
ipv6_del_addr() down to fix the UAF. [0]: BUG:
KASAN: slab-use-after-free in
inet6_addr_del.constprop.0+0x67a/0x6b0
net/ipv6/addrconf.c:3117 Read of size 4 at addr
ffff88807b89c86c by task syz.3.1618/9593 CPU: 0
UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted
syzkaller #0 PREEMPT(full) Hardware name: Google
Google Compute Engine/Google Compute Engine, BIOS
Google 10/25/2025 Call Trace: <TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378
[inline] print_report+0xcd/0x630
mm/kasan/report.c:482 kasan_report+0xe0/0x110
mm/kasan/report.c:595
inet6_addr_del.constprop.0+0x67a/0x6b0
net/ipv6/addrconf.c:3117
addrconf_del_ifaddr+0x11e/0x190
net/ipv6/addrconf.c:3181 inet6_ioctl+0x1e5/0x2b0
net/ipv6/af_inet6.c:582 sock_do_ioctl+0x118/0x280
net/socket.c:1254 sock_ioctl+0x227/0x6b0
net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xcd/0xf80
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:
0033:0x7f164cf8f749 Code: ff ff c3 66 2e 0f 1f 84
00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89
d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05
<48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff
ff ff f7 d8 64 89 01 48 RSP: 002b:00007f164de64038
EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX:
ffffffffffffffda RBX: 00007f164d1e5fa0 RCX:
00007f164cf8f749 RDX: 0000200000000000 RSI:
0000000000008936 RDI: 0000000000000003 RBP:
00007f164d013f91 R08: 0000000000000000 R09:
0000000000000000 R10: 0000000000000000 R11:
0000000000000246 R12: 0000000000000000 R13:
00007f164d1e6038 R14: 00007f164d1e5fa0 R15:
00007ffde15c8288 </TASK> Allocated by task
9593: kasan_save_stack+0x33/0x60
mm/kasan/common.c:56 kasan_save_track+0x14/0x30
mm/kasan/common.c:77 poison_kmalloc_redzone
mm/kasan/common.c:397 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414
kmalloc_noprof include/linux/slab.h:957 [inline]
kzalloc_noprof include/linux/slab.h:1094 [inline]
ipv6_add_addr+0x4e3/0x2010
net/ipv6/addrconf.c:1120
inet6_addr_add+0x256/0x9b0
net/ipv6/addrconf.c:3050
addrconf_add_ifaddr+0x1fc/0x450
net/ipv6/addrconf.c:3160 inet6_ioctl+0x103/0x2b0
net/ipv6/af_inet6.c:580 sock_do_ioctl+0x118/0x280
net/socket.c:1254 sock_ioctl+0x227/0x6b0
net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xcd/0xf80
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by
task 6099: kasan_save_stack+0x33/0x60
mm/kasan/common.c:56 kasan_save_track+0x14/0x30
mm/kasan/common.c:77
kasan_save_free_info+0x3b/0x60
mm/kasan/generic.c:584 poison_slab_object
mm/kasan/common.c:252 [inline]
__kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284
kasan_slab_free include/linux/kasan.h:234 [inline]
slab_free_hook mm/slub.c:2540 [inline]
slab_free_freelist_hook mm/slub.c:2569 [inline]
slab_free_bulk mm/slub.c:6696 [inline]
kmem_cache_free_bulk mm/slub.c:7383 [inline]
kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362
kfree_bulk include/linux/slab.h:830 [inline]
kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523
kvfree_rcu_drain_ready mm/slab_common.c:1728
[inline] kfree_rcu_monitor+0x1d0/0x2f0
mm/slab_common.c:1801
process_one_work+0x9ba/0x1b20
kernel/workqueue.c:3257 process_scheduled_works
kernel/workqu ---truncated--- |
| CVE-2026-23011 |
In the Linux kernel, the
following vulnerability has been resolved: ipv4:
ip_gre: make ipgre_header() robust Analog to
commit db5b4e39c4e6 ("ip6_gre: make
ip6gre_header() robust") Over the years, syzbot
found many ways to crash the kernel in
ipgre_header() [1]. This involves team or bonding
drivers ability to dynamically change their
dev->needed_headroom and/or
dev->hard_header_len In this particular crash
mld_newpack() allocated an skb with a too small
reserve/headroom, and by the time mld_sendpack()
was called, syzbot managed to attach an ipgre
device. [1] skbuff: skb_under_panic:
text:ffffffff89ea3cb7 len:2030915468
put:2030915372 head:ffff888058b43000
data:ffff887fdfa6e194 tail:0x120 end:0x6c0
dev:team0 kernel BUG at net/core/skbuff.c:213 !
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU:
1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted
syzkaller #0 PREEMPT(full) Hardware name: Google
Google Compute Engine/Google Compute Engine, BIOS
Google 10/25/2025 Workqueue: mld mld_ifc_work RIP:
0010:skb_panic+0x157/0x160 net/core/skbuff.c:213
Call Trace: <TASK> skb_under_panic
net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0
net/core/skbuff.c:2641 ipgre_header+0x67/0x290
net/ipv4/ip_gre.c:897 dev_hard_header
include/linux/netdevice.h:3436 [inline]
neigh_connected_output+0x286/0x460
net/core/neighbour.c:1618 NF_HOOK_COND
include/linux/netfilter.h:307 [inline]
ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247
NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318
mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855
mld_send_cr net/ipv6/mcast.c:2154 [inline]
mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693
process_one_work kernel/workqueue.c:3257 [inline]
process_scheduled_works+0xad1/0x1770
kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0
kernel/workqueue.c:3421 kthread+0x711/0x8a0
kernel/kthread.c:463 ret_from_fork+0x510/0xa50
arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30
arch/x86/entry/entry_64.S:246 |
| CVE-2026-23019 |
In the Linux kernel, the
following vulnerability has been resolved: net:
marvell: prestera: fix NULL dereference on
devlink_alloc() failure devlink_alloc() may return
NULL on allocation failure, but
prestera_devlink_alloc() unconditionally calls
devlink_priv() on the returned pointer. This leads
to a NULL pointer dereference if devlink
allocation fails. Add a check for a NULL devlink
pointer and return NULL early to avoid the
crash. |
| CVE-2026-23020 |
In the Linux kernel, the
following vulnerability has been resolved: net:
3com: 3c59x: fix possible null dereference in
vortex_probe1() pdev can be null and free_ring:
can be called in 1297 with a null pdev. |
| CVE-2026-23021 |
In the Linux kernel, the
following vulnerability has been resolved: net:
usb: pegasus: fix memory leak in
update_eth_regs_async() When asynchronously
writing to the device registers and if
usb_submit_urb() fail, the code fail to release
allocated to this point resources. |
| CVE-2026-23025 |
In the Linux kernel, the
following vulnerability has been resolved:
mm/page_alloc: prevent pcp corruption with SMP=n
The kernel test robot has reported: BUG: spinlock
trylock failure on UP on CPU#0, kcompactd0/28
lock: 0xffff888807e35ef0, .magic: dead4ead,
.owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0
PID: 28 Comm: kcompactd0 Not tainted
6.18.0-rc5-00127-ga06157804399 #1 PREEMPT
8cc09ef94dcec767faa911515ce9e609c45db470 Call
Trace: <IRQ> __dump_stack
(lib/dump_stack.c:95) dump_stack_lvl
(lib/dump_stack.c:123) dump_stack
(lib/dump_stack.c:130) spin_dump
(kernel/locking/spinlock_debug.c:71)
do_raw_spin_trylock
(kernel/locking/spinlock_debug.c:?)
_raw_spin_trylock
(include/linux/spinlock_api_smp.h:89
kernel/locking/spinlock.c:138) __free_frozen_pages
(mm/page_alloc.c:2973) ___free_pages
(mm/page_alloc.c:5295) __free_pages
(mm/page_alloc.c:5334) tlb_remove_table_rcu
(include/linux/mm.h:? include/linux/mm.h:3122
include/asm-generic/tlb.h:220 mm/mmu_gather.c:227
mm/mmu_gather.c:290) ? __cfi_tlb_remove_table_rcu
(mm/mmu_gather.c:289) ? rcu_core
(kernel/rcu/tree.c:?) rcu_core
(include/linux/rcupdate.h:341
kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861)
rcu_core_si (kernel/rcu/tree.c:2879)
handle_softirqs
(arch/x86/include/asm/jump_label.h:36
include/trace/events/irq.h:142
kernel/softirq.c:623) __irq_exit_rcu
(arch/x86/include/asm/jump_label.h:36
kernel/softirq.c:725) irq_exit_rcu
(kernel/softirq.c:741) sysvec_apic_timer_interrupt
(arch/x86/kernel/apic/apic.c:1052) </IRQ>
<TASK> RIP: 0010:_raw_spin_unlock_irqrestore
(arch/x86/include/asm/preempt.h:95
include/linux/spinlock_api_smp.h:152
kernel/locking/spinlock.c:194) free_pcppages_bulk
(mm/page_alloc.c:1494) drain_pages_zone
(include/linux/spinlock.h:391
mm/page_alloc.c:2632) __drain_all_pages
(mm/page_alloc.c:2731) drain_all_pages
(mm/page_alloc.c:2747) kcompactd
(mm/compaction.c:3115) kthread
(kernel/kthread.c:465) ? __cfi_kcompactd
(mm/compaction.c:3166) ? __cfi_kthread
(kernel/kthread.c:412) ret_from_fork
(arch/x86/kernel/process.c:164) ? __cfi_kthread
(kernel/kthread.c:412) ret_from_fork_asm
(arch/x86/entry/entry_64.S:255) </TASK>
Matthew has analyzed the report and identified
that in drain_page_zone() we are in a section
protected by spin_lock(&pcp->lock) and then
get an interrupt that attempts spin_trylock() on
the same lock. The code is designed to work this
way without disabling IRQs and occasionally fail
the trylock with a fallback. However, the SMP=n
spinlock implementation assumes spin_trylock()
will always succeed, and thus it's normally a
no-op. Here the enabled lock debugging catches the
problem, but otherwise it could cause a corruption
of the pcp structure. The problem has been
introduced by commit 574907741599 ("mm/page_alloc:
leave IRQs enabled for per-cpu page allocations").
The pcp locking scheme recognizes the need for
disabling IRQs to prevent nesting spin_trylock()
sections on SMP=n, but the need to prevent the
nesting in spin_lock() has not been recognized.
Fix it by introducing local wrappers that change
the spin_lock() to spin_lock_iqsave() with SMP=n
and use them in all places that do
spin_lock(&pcp->lock). [vbabka@suse.cz: add
pcp_ prefix to the spin_lock_irqsave wrappers, per
Steven] |
| CVE-2026-23026 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: qcom: gpi: Fix memory leak in
gpi_peripheral_config() Fix a memory leak in
gpi_peripheral_config() where the original memory
pointed to by gchan->config could be lost if
krealloc() fails. The issue occurs when: 1.
gchan->config points to previously allocated
memory 2. krealloc() fails and returns NULL 3. The
function directly assigns NULL to
gchan->config, losing the reference to the
original memory 4. The original memory becomes
unreachable and cannot be freed Fix this by using
a temporary variable to hold the krealloc() result
and only updating gchan->config when the
allocation succeeds. Found via static analysis and
code review. |
| CVE-2026-23030 |
In the Linux kernel, the
following vulnerability has been resolved: phy:
rockchip: inno-usb2: Fix a double free bug in
rockchip_usb2phy_probe() The
for_each_available_child_of_node() calls
of_node_put() to release child_np in each success
loop. After breaking from the loop with the
child_np has been released, the code will jump to
the put_child label and will call the
of_node_put() again if the
devm_request_threaded_irq() fails. These cause a
double free bug. Fix by returning directly to
avoid the duplicate of_node_put(). |
| CVE-2026-23031 |
In the Linux kernel, the
following vulnerability has been resolved: can:
gs_usb: gs_usb_receive_bulk_callback(): fix URB
memory leak In gs_can_open(), the URBs for USB-in
transfers are allocated, added to the
parent->rx_submitted anchor and submitted. In
the complete callback
gs_usb_receive_bulk_callback(), the URB is
processed and resubmitted. In gs_can_close() the
URBs are freed by calling
usb_kill_anchored_urbs(parent->rx_submitted).
However, this does not take into account that the
USB framework unanchors the URB before the
complete function is called. This means that once
an in-URB has been completed, it is no longer
anchored and is ultimately not released in
gs_can_close(). Fix the memory leak by anchoring
the URB in the gs_usb_receive_bulk_callback() to
the parent->rx_submitted anchor. |
| CVE-2026-23032 |
In the Linux kernel, the
following vulnerability has been resolved:
null_blk: fix kmemleak by releasing references to
fault configfs items When
CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is
enabled, the null-blk driver sets up fault
injection support by creating the timeout_inject,
requeue_inject, and init_hctx_fault_inject
configfs items as children of the top-level nullbX
configfs group. However, when the nullbX device is
removed, the references taken to these
fault-config configfs items are not released. As a
result, kmemleak reports a memory leak, for
example: unreferenced object 0xc00000021ff25c40
(size 32): comm "mkdir", pid 10665, jiffies
4322121578 hex dump (first 32 bytes): 69 6e 69 74
5f 68 63 74 78 5f 66 61 75 6c 74 5f
init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00
00 00 00 00 00 inject.......... backtrace (crc
1a018c86):
__kmalloc_node_track_caller_noprof+0x494/0xbd8
kvasprintf+0x74/0xf4
config_item_set_name+0xf0/0x104
config_group_init_type_name+0x48/0xfc
fault_config_init+0x48/0xf0 0xc0080000180559e4
configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604
do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8
system_call_exception+0x1b0/0x4f0
system_call_vectored_common+0x15c/0x2ec Fix this
by explicitly releasing the references to the
fault-config configfs items when dropping the
reference to the top-level nullbX configfs
group. |
| CVE-2026-23033 |
In the Linux kernel, the
following vulnerability has been resolved:
dmaengine: omap-dma: fix dma_pool resource leak in
error paths The dma_pool created by
dma_pool_create() is not destroyed when
dma_async_device_register() or
of_dma_controller_register() fails, causing a
resource leak in the probe error paths. Add
dma_pool_destroy() in both error paths to properly
release the allocated dma_pool resource. |
| CVE-2026-23035 |
In the Linux kernel, the
following vulnerability has been resolved:
net/mlx5e: Pass netdev to mlx5e_destroy_netdev
instead of priv mlx5e_priv is an unstable
structure that can be memset(0) if profile
attaching fails. Pass netdev to
mlx5e_destroy_netdev() to guarantee it will work
on a valid netdev. On mlx5e_remove: Check validity
of priv->profile, before attempting to cleanup
any resources that might be not there. This fixes
a kernel oops in mlx5e_remove when switchdev mode
fails due to change profile failure. $ devlink dev
eswitch set pci/0000:00:03.0 mode switchdev Error:
mlx5_core: Failed setting eswitch to offloads.
dmesg: workqueue: Failed to create a rescuer
kthread for wq "mlx5e": -EINTR mlx5_core
0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid
37199): mlx5e_priv_init failed, err=-12 mlx5_core
0012:03:00.1 gpu3rdma1:
mlx5e_netdev_change_profile: new profile init
failed, -12 workqueue: Failed to create a rescuer
kthread for wq "mlx5e": -EINTR mlx5_core
0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid
37199): mlx5e_priv_init failed, err=-12 mlx5_core
0012:03:00.1 gpu3rdma1:
mlx5e_netdev_change_profile: failed to rollback to
orig profile, -12 $ devlink dev reload
pci/0000:00:03.0 ==> oops BUG: kernel NULL
pointer dereference, address: 0000000000000370 PGD
0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15
UID: 0 PID: 520 Comm: devlink Not tainted
6.18.0-rc5+ #115 PREEMPT(voluntary) Hardware name:
QEMU Standard PC (Q35 + ICH9, 2009), BIOS
1.16.3-2.fc40 04/01/2014 RIP:
0010:mlx5e_dcbnl_dscp_app+0x23/0x100 RSP:
0018:ffffc9000083f8b8 EFLAGS: 00010286 RAX:
ffff8881126fc380 RBX: ffff8881015ac400 RCX:
ffffffff826ffc45 RDX: 0000000000000000 RSI:
0000000000000001 RDI: ffff8881035109c0 RBP:
ffff8881035109c0 R08: ffff888101e3e838 R09:
ffff888100264e10 R10: ffffc9000083f898 R11:
ffffc9000083f8a0 R12: ffff888101b921a0 R13:
ffff888101b921a0 R14: ffff8881015ac9a0 R15:
ffff8881015ac400 FS: 00007f789a3c8740(0000)
GS:ffff88856aa59000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000370 CR3: 000000010b6c0001 CR4:
0000000000370ef0 Call Trace: <TASK>
mlx5e_remove+0x57/0x110
device_release_driver_internal+0x19c/0x200
bus_remove_device+0xc6/0x130
device_del+0x160/0x3d0 ?
devl_param_driverinit_value_get+0x2d/0x90
mlx5_detach_device+0x89/0xe0
mlx5_unload_one_devl_locked+0x3a/0x70
mlx5_devlink_reload_down+0xc8/0x220
devlink_reload+0x7d/0x260
devlink_nl_reload_doit+0x45b/0x5a0
genl_family_rcv_msg_doit+0xe8/0x140 |
| CVE-2026-23037 |
In the Linux kernel, the
following vulnerability has been resolved: can:
etas_es58x: allow partial RX URB allocation to
succeed When es58x_alloc_rx_urbs() fails to
allocate the requested number of URBs but succeeds
in allocating some, it returns an error code. This
causes es58x_open() to return early, skipping the
cleanup label 'free_urbs', which leads to the
anchored URBs being leaked. As pointed out by
maintainer Vincent Mailhol, the driver is designed
to handle partial URB allocation gracefully.
Therefore, partial allocation should not be
treated as a fatal error. Modify
es58x_alloc_rx_urbs() to return 0 if at least one
URB has been allocated, restoring the intended
behavior and preventing the leak in
es58x_open(). |
| CVE-2026-23038 |
In the Linux kernel, the
following vulnerability has been resolved:
pnfs/flexfiles: Fix memory leak in
nfs4_ff_alloc_deviceid_node() In
nfs4_ff_alloc_deviceid_node(), if the allocation
for ds_versions fails, the function jumps to the
out_scratch label without freeing the already
allocated dsaddrs list, leading to a memory leak.
Fix this by jumping to the out_err_drain_dsaddrs
label, which properly frees the dsaddrs list
before cleaning up other resources. |
| CVE-2026-23047 |
In the Linux kernel, the
following vulnerability has been resolved:
libceph: make calc_target() set t->paused, not
just clear it Currently calc_target() clears
t->paused if the request shouldn't be paused
anymore, but doesn't ever set t->paused even
though it's able to determine when the request
should be paused. Setting t->paused is left to
__submit_request() which is fine for regular
requests but doesn't work for linger requests --
since __submit_request() doesn't operate on linger
requests, there is nowhere for lreq->t.paused
to be set. One consequence of this is that watches
don't get reestablished on paused -> unpaused
transitions in cases where requests have been
paused long enough for the (paused) unwatch
request to time out and for the subsequent
(re)watch request to enter the paused state. On
top of the watch not getting reestablished,
rbd_reregister_watch() gets stuck with
rbd_dev->watch_mutex held: rbd_register_watch
__rbd_register_watch ceph_osdc_watch
linger_reg_commit_wait It's waiting for
lreq->reg_commit_wait to be completed, but for
that to happen the respective request needs to end
up on need_resend_linger list and be kicked when
requests are unpaused. There is no chance for that
if the request in question is never marked paused
in the first place. The fact that
rbd_dev->watch_mutex remains taken out forever
then prevents the image from getting unmapped --
"rbd unmap" would inevitably hang in D state on an
attempt to grab the mutex. |
| CVE-2026-23049 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/panel-simple: fix connector type for DataImage
SCF0700C48GGU18 panel The connector type for the
DataImage SCF0700C48GGU18 panel is missing and
devm_drm_panel_bridge_add() requires connector
type to be set. This leads to a warning and a
backtrace in the kernel log and panel does not
work: " WARNING: CPU: 3 PID: 38 at
drivers/gpu/drm/bridge/panel.c:379
devm_drm_of_get_bridge+0xac/0xb8 " The warning is
triggered by a check for valid connector type in
devm_drm_panel_bridge_add(). If there is no valid
connector type set for a panel, the warning is
printed and panel is not added. Fill in the
missing connector type to fix the warning and make
the panel operational once again. |
| CVE-2026-23050 |
In the Linux kernel, the
following vulnerability has been resolved: pNFS:
Fix a deadlock when returning a delegation during
open() Ben Coddington reports seeing a hang in the
following stack trace: 0 [ffffd0b50e1774e0]
__schedule at ffffffff9ca05415 1
[ffffd0b50e177548] schedule at ffffffff9ca05717 2
[ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3
[ffffd0b50e177568] __wait_on_bit at
ffffffff9ca05cfb 4 [ffffd0b50e1775c8]
out_of_line_wait_on_bit at ffffffff9ca05ea5 5
[ffffd0b50e177618] pnfs_roc at ffffffffc154207b
[nfsv4] 6 [ffffd0b50e1776b8]
_nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4]
7 [ffffd0b50e177788] nfs4_proc_delegreturn at
ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8]
nfs_do_return_delegation at ffffffffc1523e41
[nfsv4] 9 [ffffd0b50e177838]
nfs_inode_set_delegation at ffffffffc1524a75
[nfsv4] 10 [ffffd0b50e177888]
nfs4_process_delegation at ffffffffc14f41dd
[nfsv4] 11 [ffffd0b50e1778a0]
_nfs4_opendata_to_nfs4_state at ffffffffc1503edf
[nfsv4] 12 [ffffd0b50e1778c0]
_nfs4_open_and_get_state at ffffffffc1504e56
[nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at
ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8]
nfs4_do_open at ffffffffc150559c [nfsv4] 15
[ffffd0b50e177a80] nfs4_atomic_open at
ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0]
nfs4_file_open at ffffffffc15219be [nfsv4] 17
[ffffd0b50e177b78] do_dentry_open at
ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at
ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open
at ffffffff9c0a0935 The issue is that the
delegreturn is being asked to wait for a layout
return that cannot complete because a state
recovery was initiated. The state recovery cannot
complete until the open() finishes processing the
delegations it was given. The solution is to
propagate the existing flags that indicate a
non-blocking call to the function pnfs_roc(), so
that it knows not to wait in this
situation. |
| CVE-2026-23053 |
In the Linux kernel, the
following vulnerability has been resolved: NFS:
Fix a deadlock involving nfs_release_folio() Wang
Zhaolong reports a deadlock involving NFSv4.1
state recovery waiting on kthreadd, which is
attempting to reclaim memory by calling
nfs_release_folio(). The latter cannot make
progress due to state recovery being needed. It
seems that the only safe thing to do here is to
kick off a writeback of the folio, without waiting
for completion, or else kicking off an
asynchronous commit. |
| CVE-2026-23054 |
In the Linux kernel, the
following vulnerability has been resolved: net:
hv_netvsc: reject RSS hash key programming without
RX indirection table RSS configuration requires a
valid RX indirection table. When the device
reports a single receive queue,
rndis_filter_device_add() does not allocate an
indirection table, accepting RSS hash key updates
in this state leads to a hang. Fix this by gating
netvsc_set_rxfh() on ndc->rx_table_sz and
return -EOPNOTSUPP when the table is absent. This
aligns set_rxfh with the device capabilities and
prevents incorrect behavior. |
| CVE-2026-23056 |
In the Linux kernel, the
following vulnerability has been resolved: uacce:
implement mremap in uacce_vm_ops to return -EPERM
The current uacce_vm_ops does not support the
mremap operation of vm_operations_struct.
Implement .mremap to return -EPERM to remind
users. The reason we need to explicitly disable
mremap is that when the driver does not implement
.mremap, it uses the default mremap method. This
could lead to a risk scenario: An application
might first mmap address p1, then mremap to p2,
followed by munmap(p1), and finally munmap(p2).
Since the default mremap copies the original vma's
vm_private_data (i.e., q) to the new vma, both
munmap operations would trigger vma_close, causing
q->qfr to be freed twice(qfr will be set to
null here, so repeated release is ok). |
| CVE-2026-23057 |
In the Linux kernel, the
following vulnerability has been resolved:
vsock/virtio: Coalesce only linear skb
vsock/virtio common tries to coalesce buffers in
rx queue: if a linear skb (with a spare tail room)
is followed by a small skb (length limited by
GOOD_COPY_LEN = 128), an attempt is made to join
them. Since the introduction of MSG_ZEROCOPY
support, assumption that a small skb will always
be linear is incorrect. In the zerocopy case, data
is lost and the linear skb is appended with
uninitialized kernel memory. Of all 3 supported
virtio-based transports, only loopback-transport
is affected. G2H virtio-transport rx queue
operates on explicitly linear skbs; see
virtio_vsock_alloc_linear_skb() in
virtio_vsock_rx_fill(). H2G vhost-transport may
allocate non-linear skbs, but only for sizes that
are not considered for coalescence; see
PAGE_ALLOC_COSTLY_ORDER in
virtio_vsock_alloc_skb(). Ensure only linear skbs
are coalesced. Note that skb_tailroom(last_skb)
> 0 guarantees last_skb is linear. |
| CVE-2026-23058 |
In the Linux kernel, the
following vulnerability has been resolved: can:
ems_usb: ems_usb_read_bulk_callback(): fix URB
memory leak Fix similar memory leak as in commit
7352e1d5932a ("can: gs_usb:
gs_usb_receive_bulk_callback(): fix URB memory
leak"). In ems_usb_open(), the URBs for USB-in
transfers are allocated, added to the
dev->rx_submitted anchor and submitted. In the
complete callback ems_usb_read_bulk_callback(),
the URBs are processed and resubmitted. In
ems_usb_close() the URBs are freed by calling
usb_kill_anchored_urbs(&dev->rx_submitted).
However, this does not take into account that the
USB framework unanchors the URB before the
complete function is called. This means that once
an in-URB has been completed, it is no longer
anchored and is ultimately not released in
ems_usb_close(). Fix the memory leak by anchoring
the URB in the ems_usb_read_bulk_callback() to the
dev->rx_submitted anchor. |
| CVE-2026-23059 |
In the Linux kernel, the
following vulnerability has been resolved: scsi:
qla2xxx: Sanitize payload size to prevent member
overflow In qla27xx_copy_fpin_pkt() and
qla27xx_copy_multiple_pkt(), the frame_size
reported by firmware is used to calculate the copy
length into item->iocb. However, the iocb
member is defined as a fixed-size 64-byte array
within struct purex_item. If the reported
frame_size exceeds 64 bytes, subsequent memcpy
calls will overflow the iocb member boundary.
While extra memory might be allocated, this
cross-member write is unsafe and triggers warnings
under CONFIG_FORTIFY_SOURCE. Fix this by capping
total_bytes to the size of the iocb member (64
bytes) before allocation and copying. This ensures
all copies remain within the bounds of the
destination structure member. |
| CVE-2026-23061 |
In the Linux kernel, the
following vulnerability has been resolved: can:
kvaser_usb: kvaser_usb_read_bulk_callback(): fix
URB memory leak Fix similar memory leak as in
commit 7352e1d5932a ("can: gs_usb:
gs_usb_receive_bulk_callback(): fix URB memory
leak"). In kvaser_usb_set_{,data_}bittiming()
-> kvaser_usb_setup_rx_urbs(), the URBs for
USB-in transfers are allocated, added to the
dev->rx_submitted anchor and submitted. In the
complete callback kvaser_usb_read_bulk_callback(),
the URBs are processed and resubmitted. In
kvaser_usb_remove_interfaces() the URBs are freed
by calling
usb_kill_anchored_urbs(&dev->rx_submitted).
However, this does not take into account that the
USB framework unanchors the URB before the
complete function is called. This means that once
an in-URB has been completed, it is no longer
anchored and is ultimately not released in
usb_kill_anchored_urbs(). Fix the memory leak by
anchoring the URB in the
kvaser_usb_read_bulk_callback() to the
dev->rx_submitted anchor. |
| CVE-2026-23062 |
In the Linux kernel, the
following vulnerability has been resolved:
platform/x86: hp-bioscfg: Fix kernel panic in
GET_INSTANCE_ID macro The GET_INSTANCE_ID macro
that caused a kernel panic when accessing sysfs
attributes: 1. Off-by-one error: The loop
condition used '<=' instead of '<', causing
access beyond array bounds. Since array indices
are 0-based and go from 0 to instances_count-1,
the loop should use '<'. 2. Missing NULL check:
The code dereferenced attr_name_kobj->name
without checking if attr_name_kobj was NULL,
causing a null pointer dereference in
min_length_show() and other attribute show
functions. The panic occurred when fwupd tried to
read BIOS configuration attributes: Oops: general
protection fault [#1] SMP KASAN NOPTI KASAN:
null-ptr-deref in range
[0x0000000000000000-0x0000000000000007] RIP:
0010:min_length_show+0xcf/0x1d0 [hp_bioscfg] Add a
NULL check for attr_name_kobj before dereferencing
and corrects the loop boundary to match the
pattern used elsewhere in the driver. |
| CVE-2026-23063 |
In the Linux kernel, the
following vulnerability has been resolved: uacce:
ensure safe queue release with state management
Directly calling `put_queue` carries risks since
it cannot guarantee that resources of
`uacce_queue` have been fully released beforehand.
So adding a `stop_queue` operation for the
UACCE_CMD_PUT_Q command and leaving the
`put_queue` operation to the final resource
release ensures safety. Queue states are defined
as follows: - UACCE_Q_ZOMBIE: Initial state -
UACCE_Q_INIT: After opening `uacce` -
UACCE_Q_STARTED: After `start` is issued via
`ioctl` When executing `poweroff -f` in virt while
accelerator are still working,
`uacce_fops_release` and `uacce_remove` may
execute concurrently. This can cause
`uacce_put_queue` within `uacce_fops_release` to
access a NULL `ops` pointer. Therefore, add state
checks to prevent accessing freed
pointers. |
| CVE-2026-23064 |
In the Linux kernel, the
following vulnerability has been resolved:
net/sched: act_ife: avoid possible NULL deref
tcf_ife_encode() must make sure ife_encode() does
not return NULL. syzbot reported: Oops: general
protection fault, probably for non-canonical
address 0xdffffc0000000000: 0000 [#1] SMP KASAN
NOPTI KASAN: null-ptr-deref in range
[0x0000000000000000-0x0000000000000007] RIP:
0010:ife_tlv_meta_encode+0x41/0xa0
net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm:
syz.0.696 Not tainted syzkaller #0 PREEMPT(full)
Call Trace: <TASK>
ife_encode_meta_u32+0x153/0x180
net/sched/act_ife.c:101 tcf_ife_encode
net/sched/act_ife.c:841 [inline]
tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877
tc_act include/net/tc_wrapper.h:130 [inline]
tcf_action_exec+0x1c0/0xa20
net/sched/act_api.c:1152 tcf_exts_exec
include/net/pkt_cls.h:349 [inline]
mall_classify+0x1a0/0x2a0
net/sched/cls_matchall.c:42 tc_classify
include/net/tc_wrapper.h:197 [inline]
__tcf_classify net/sched/cls_api.c:1764 [inline]
tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860
multiq_classify net/sched/sch_multiq.c:39 [inline]
multiq_enqueue+0xe0/0x510
net/sched/sch_multiq.c:66
dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147
__dev_xmit_skb net/core/dev.c:4262 [inline]
__dev_queue_xmit+0x2998/0x46c0
net/core/dev.c:4798 |
| CVE-2026-23065 |
In the Linux kernel, the
following vulnerability has been resolved:
platform/x86/amd: Fix memory leak in wbrf_record()
The tmp buffer is allocated using kcalloc() but is
not freed if acpi_evaluate_dsm() fails. This
causes a memory leak in the error path. Fix this
by explicitly freeing the tmp buffer in the error
handling path of acpi_evaluate_dsm(). |
| CVE-2026-23068 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
spi-sprd-adi: Fix double free in probe error path
The driver currently uses spi_alloc_host() to
allocate the controller but registers it using
devm_spi_register_controller(). If
devm_register_restart_handler() fails, the code
jumps to the put_ctlr label and calls
spi_controller_put(). However, since the
controller was registered via a devm function, the
device core will automatically call
spi_controller_put() again when the probe fails.
This results in a double-free of the
spi_controller structure. Fix this by switching to
devm_spi_alloc_host() and removing the manual
spi_controller_put() call. |
| CVE-2026-23069 |
In the Linux kernel, the
following vulnerability has been resolved:
vsock/virtio: fix potential underflow in
virtio_transport_get_credit() The credit
calculation in virtio_transport_get_credit() uses
unsigned arithmetic: ret = vvs->peer_buf_alloc
- (vvs->tx_cnt - vvs->peer_fwd_cnt); If the
peer shrinks its advertised buffer
(peer_buf_alloc) while bytes are in flight, the
subtraction can underflow and produce a large
positive value, potentially allowing more data to
be queued than the peer can handle. Reuse
virtio_transport_has_space() which already handles
this case and add a comment to make it clear why
we are doing that. [Stefano: use
virtio_transport_has_space() instead of
duplicating the code] [Stefano: tweak the commit
message] |
| CVE-2026-23071 |
In the Linux kernel, the
following vulnerability has been resolved: regmap:
Fix race condition in hwspinlock irqsave routine
Previously, the address of the shared member
'&map->spinlock_flags' was passed directly
to 'hwspin_lock_timeout_irqsave'. This creates a
race condition where multiple contexts contending
for the lock could overwrite the shared flags
variable, potentially corrupting the state for the
current lock owner. Fix this by using a local
stack variable 'flags' to store the IRQ state
temporarily. |
| CVE-2026-23073 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
rsi: Fix memory corruption due to not set vif
driver data size The struct ieee80211_vif contains
trailing space for vif driver data, when struct
ieee80211_vif is allocated, the total memory size
that is allocated is sizeof(struct ieee80211_vif)
+ size of vif driver data. The size of vif driver
data is set by each WiFi driver as needed. The
RSI911x driver does not set vif driver data size,
no trailing space for vif driver data is therefore
allocated past struct ieee80211_vif . The RSI911x
driver does however use the vif driver data to
store its vif driver data structure "struct
vif_priv". An access to vif->drv_priv leads to
access out of struct ieee80211_vif bounds and
corruption of some memory. In case of the failure
observed locally, rsi_mac80211_add_interface()
would write struct vif_priv *vif_info = (struct
vif_priv *)vif->drv_priv; vif_info->vap_id =
vap_idx. This write corrupts struct fq_tin member
struct list_head new_flows . The flow =
list_first_entry(head, struct fq_flow, flowchain);
in fq_tin_reset() then reports non-NULL bogus
address, which when accessed causes a crash. The
trigger is very simple, boot the machine with
init=/bin/sh , mount devtmpfs, sysfs, procfs, and
then do "ip link set wlan0 up", "sleep 1", "ip
link set wlan0 down" and the crash occurs. Fix
this by setting the correct size of vif driver
data, which is the size of "struct vif_priv", so
that memory is allocated and the driver can store
its driver data in it, instead of corrupting
memory around it. |
| CVE-2026-23075 |
In the Linux kernel, the
following vulnerability has been resolved: can:
esd_usb: esd_usb_read_bulk_callback(): fix URB
memory leak Fix similar memory leak as in commit
7352e1d5932a ("can: gs_usb:
gs_usb_receive_bulk_callback(): fix URB memory
leak"). In esd_usb_open(), the URBs for USB-in
transfers are allocated, added to the
dev->rx_submitted anchor and submitted. In the
complete callback esd_usb_read_bulk_callback(),
the URBs are processed and resubmitted. In
esd_usb_close() the URBs are freed by calling
usb_kill_anchored_urbs(&dev->rx_submitted).
However, this does not take into account that the
USB framework unanchors the URB before the
complete function is called. This means that once
an in-URB has been completed, it is no longer
anchored and is ultimately not released in
esd_usb_close(). Fix the memory leak by anchoring
the URB in the esd_usb_read_bulk_callback() to the
dev->rx_submitted anchor. |
| CVE-2026-23076 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
ctxfi: Fix potential OOB access in audio mixer
handling In the audio mixer handling code of ctxfi
driver, the conf field is used as a kind of loop
index, and it's referred in the index callbacks
(amixer_index() and sum_index()). As spotted
recently by fuzzers, the current code causes OOB
access at those functions. | UBSAN:
array-index-out-of-bounds in
/build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48
| index 8 is out of range for type 'unsigned char
[8]' After the analysis, the cause was found to be
the lack of the proper (re-)initialization of conj
field. This patch addresses those OOB accesses by
adding the proper initializations of the loop
indices. |
| CVE-2026-23078 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
scarlett2: Fix buffer overflow in config retrieval
The scarlett2_usb_get_config() function has a
logic error in the endianness conversion code that
can cause buffer overflows when count > 1. The
code checks `if (size == 2)` where `size` is the
total buffer size in bytes, then loops `count`
times treating each element as u16 (2 bytes). This
causes the loop to access `count * 2` bytes when
the buffer only has `size` bytes allocated. Fix by
checking the element size (config_item->size)
instead of the total buffer size. This ensures the
endianness conversion matches the actual element
type. |
| CVE-2026-23080 |
In the Linux kernel, the
following vulnerability has been resolved: can:
mcba_usb: mcba_usb_read_bulk_callback(): fix URB
memory leak Fix similar memory leak as in commit
7352e1d5932a ("can: gs_usb:
gs_usb_receive_bulk_callback(): fix URB memory
leak"). In mcba_usb_probe() ->
mcba_usb_start(), the URBs for USB-in transfers
are allocated, added to the priv->rx_submitted
anchor and submitted. In the complete callback
mcba_usb_read_bulk_callback(), the URBs are
processed and resubmitted. In mcba_usb_close()
-> mcba_urb_unlink() the URBs are freed by
calling
usb_kill_anchored_urbs(&priv->rx_submitted).
However, this does not take into account that the
USB framework unanchors the URB before the
complete function is called. This means that once
an in-URB has been completed, it is no longer
anchored and is ultimately not released in
usb_kill_anchored_urbs(). Fix the memory leak by
anchoring the URB in the
mcba_usb_read_bulk_callback()to the
priv->rx_submitted anchor. |
| CVE-2026-23083 |
In the Linux kernel, the
following vulnerability has been resolved: fou:
Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv()
has the same problem mentioned in the previous
patch. If FOU_ATTR_IPPROTO is set to 0, skb is not
freed by fou_udp_recv() nor "resubmit"-ted in
ip_protocol_deliver_rcu(). Let's forbid 0 for
FOU_ATTR_IPPROTO. |
| CVE-2026-23084 |
In the Linux kernel, the
following vulnerability has been resolved: be2net:
Fix NULL pointer dereference in
be_cmd_get_mac_from_list When the parameter
pmac_id_valid argument of
be_cmd_get_mac_from_list() is set to false, the
driver may request the PMAC_ID from the firmware
of the network card, and this function will store
that PMAC_ID at the provided address pmac_id. This
is the contract of this function. However, there
is a location within the driver where both
pmac_id_valid == false and pmac_id == NULL are
being passed. This could result in dereferencing a
NULL pointer. To resolve this issue, it is
necessary to pass the address of a stub variable
to the function. |
| CVE-2026-23085 |
In the Linux kernel, the
following vulnerability has been resolved:
irqchip/gic-v3-its: Avoid truncating memory
addresses On 32-bit machines with CONFIG_ARM_LPAE,
it is possible for lowmem allocations to be backed
by addresses physical memory above the 32-bit
address limit, as found while experimenting with
larger VMSPLIT configurations. This caused the
qemu virt model to crash in the GICv3 driver,
which allocates the 'itt' object using GFP_KERNEL.
Since all memory below the 4GB physical address
limit is in ZONE_DMA in this configuration,
kmalloc() defaults to higher addresses for
ZONE_NORMAL, and the ITS driver stores the
physical address in a 32-bit 'unsigned long'
variable. Change the itt_addr variable to the
correct phys_addr_t type instead, along with all
other variables in this driver that hold a
physical address. The gicv5 driver correctly uses
u64 variables, while all other irqchip drivers
don't call virt_to_phys or similar interfaces.
It's expected that other device drivers have
similar issues, but fixing this one is sufficient
for booting a virtio based guest. |
| CVE-2026-23086 |
In the Linux kernel, the
following vulnerability has been resolved:
vsock/virtio: cap TX credit to local buffer size
The virtio transports derives its TX credit
directly from peer_buf_alloc, which is set from
the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE
value. On the host side this means that the amount
of data we are willing to queue for a connection
is scaled by a guest-chosen buffer size, rather
than the host's own vsock configuration. A
malicious guest can advertise a large buffer and
read slowly, causing the host to allocate a
correspondingly large amount of sk_buff memory.
The same thing would happen in the guest with a
malicious host, since virtio transports share the
same code base. Introduce a small helper,
virtio_transport_tx_buf_size(), that returns
min(peer_buf_alloc, buf_alloc), and use it
wherever we consume peer_buf_alloc. This ensures
the effective TX window is bounded by both the
peer's advertised buffer and our own buf_alloc
(already clamped to buffer_max_size via
SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer
cannot force the other to queue more data than
allowed by its own vsock settings. On an unpatched
Ubuntu 22.04 host (~64 GiB RAM), running a PoC
with 32 guest vsock connections advertising 2 GiB
each and reading slowly drove Slab/SUnreclaim from
~0.5 GiB to ~57 GiB; the system only recovered
after killing the QEMU process. That said, if QEMU
memory is limited with cgroups, the maximum memory
used will be limited. With this patch applied:
Before: MemFree: ~61.6 GiB Slab: ~142 MiB
SUnreclaim: ~117 MiB After 32 high-credit
connections: MemFree: ~61.5 GiB Slab: ~178 MiB
SUnreclaim: ~152 MiB Only ~35 MiB increase in
Slab/SUnreclaim, no host OOM, and the guest
remains responsive. Compatibility with non-virtio
transports: - VMCI uses the AF_VSOCK buffer knobs
to size its queue pairs per socket based on the
local vsk->buffer_* values; the remote side
cannot enlarge those queues beyond what the local
endpoint configured. - Hyper-V's vsock transport
uses fixed-size VMBus ring buffers and an MTU
bound; there is no peer-controlled credit field
comparable to peer_buf_alloc, and the remote
endpoint cannot drive in-flight kernel memory
above those ring sizes. - The loopback path reuses
virtio_transport_common.c, so it naturally follows
the same semantics as the virtio transport. This
change is limited to virtio_transport_common.c and
thus affects virtio-vsock, vhost-vsock, and
loopback, bringing them in line with the "remote
window intersected with local policy" behaviour
that VMCI and Hyper-V already effectively have.
[Stefano: small adjustments after changing the
previous patch] [Stefano: tweak the commit
message] |
| CVE-2026-23087 |
In the Linux kernel, the
following vulnerability has been resolved: scsi:
xen: scsiback: Fix potential memory leak in
scsiback_remove() Memory allocated for struct
vscsiblk_info in scsiback_probe() is not freed in
scsiback_remove() leading to potential memory
leaks on remove, as well as in the
scsiback_probe() error paths. Fix that by freeing
it in scsiback_remove(). |
| CVE-2026-23088 |
In the Linux kernel, the
following vulnerability has been resolved:
tracing: Fix crash on synthetic stacktrace field
usage When creating a synthetic event based on an
existing synthetic event that had a stacktrace
field and the new synthetic event used that field
a kernel crash occurred: ~# cd /sys/kernel/tracing
~# echo 's:stack unsigned long stack[];' >
dynamic_events ~# echo
'hist:keys=prev_pid:s0=common_stacktrace if
prev_state & 3' >>
events/sched/sched_switch/trigger ~# echo
'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)'
>> events/sched/sched_switch/trigger The
above creates a synthetic event that takes a
stacktrace when a task schedules out in a
non-running state and passes that stacktrace to
the sched_switch event when that task schedules
back in. It triggers the "stack" synthetic event
that has a stacktrace as its field (called
"stack"). ~# echo 's:syscall_stack s64 id;
unsigned long stack[];' >> dynamic_events ~#
echo 'hist:keys=common_pid:s2=stack' >>
events/synthetic/stack/trigger ~# echo
'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)'
>> events/raw_syscalls/sys_exit/trigger The
above makes another synthetic event called
"syscall_stack" that attaches the first synthetic
event (stack) to the sys_exit trace event and
records the stacktrace from the stack event with
the id of the system call that is exiting. When
enabling this event (or using it in a historgram):
~# echo 1 >
events/synthetic/syscall_stack/enable Produces a
kernel crash! BUG: unable to handle page fault for
address: 0000000000400010 #PF: supervisor read
access in kernel mode #PF: error_code(0x0000) -
not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1]
SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash Not
tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian
6.16.3-1 Hardware name: QEMU Standard PC (Q35 +
ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1
04/01/2014 RIP:
0010:trace_event_raw_event_synth+0x90/0x380 Code:
c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34
0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e
0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83
c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f
RSP: 0018:ffffd2670388f958 EFLAGS: 00010202 RAX:
ffff8ba1065cc100 RBX: 0000000000000000 RCX:
0000000000000000 RDX: 0000000000000001 RSI:
fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP:
0000000000000010 R08: ffff8ba104e76000 R09:
ffffd2670388fa50 R10: ffff8ba102dd42e0 R11:
ffffffff9a908970 R12: 0000000000400010 R13:
ffff8ba10a246400 R14: ffff8ba10a710220 R15:
fffff266ffda7b90 FS: 00007fa3bc63f740(0000)
GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000400010 CR3: 0000000107f9e003 CR4:
0000000000172ef0 Call Trace: <TASK> ?
__tracing_map_insert+0x208/0x3a0
action_trace+0x67/0x70
event_hist_trigger+0x633/0x6d0
event_triggers_call+0x82/0x130
trace_event_buffer_commit+0x19d/0x250
trace_event_raw_event_sys_exit+0x62/0xb0
syscall_exit_work+0x9d/0x140
do_syscall_64+0x20a/0x2f0 ?
trace_event_raw_event_sched_switch+0x12b/0x170 ?
save_fpregs_to_fpstate+0x3e/0x90 ?
_raw_spin_unlock+0xe/0x30 ?
finish_task_switch.isra.0+0x97/0x2c0 ?
__rseq_handle_notify_resume+0xad/0x4c0 ?
__schedule+0x4b8/0xd00 ?
restore_fpregs_from_fpstate+0x3c/0x90 ?
switch_fpu_return+0x5b/0xe0 ?
do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ?
__handle_mm_fault+0x7d1/0xf70 ?
count_memcg_events+0x167/0x1d0 ?
handle_mm_fault+0x1d7/0x2e0 ?
do_user_addr_fault+0x2c3/0x7f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e The
reason is that the stacktrace field is not labeled
as such, and is treated as a normal field and not
as a dynamic event that it is. In
trace_event_raw_event_synth() the event is field
is still treated as a dynamic array, but the
retrieval of the data is considered a normal
field, and the reference is just the meta data: //
Meta data is retrieved instead of a dynamic array
---truncated--- |
| CVE-2026-23089 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
usb-audio: Fix use-after-free in
snd_usb_mixer_free() When snd_usb_create_mixer()
fails, snd_usb_mixer_free() frees
mixer->id_elems but the controls already added
to the card still reference the freed memory.
Later when snd_card_register() runs, the OSS mixer
layer calls their callbacks and hits a
use-after-free read. Call trace:
get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411
get_min_max_with_quirks.isra.0+0x240/0x1f40
sound/usb/mixer.c:1241
mixer_ctl_feature_info+0x26b/0x490
sound/usb/mixer.c:1381
snd_mixer_oss_build_test+0x174/0x3a0
sound/core/oss/mixer_oss.c:887 ...
snd_card_register+0x4ed/0x6d0
sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90
sound/usb/card.c:1025 Fix by calling
snd_ctl_remove() for all mixer controls before
freeing id_elems. We save the next pointer first
because snd_ctl_remove() frees the current
element. |
| CVE-2026-23090 |
In the Linux kernel, the
following vulnerability has been resolved:
slimbus: core: fix device reference leak on report
present Slimbus devices can be allocated
dynamically upon reception of report-present
messages. Make sure to drop the reference taken
when looking up already registered devices. Note
that this requires taking an extra reference in
case the device has not yet been registered and
has to be allocated. |
| CVE-2026-23091 |
In the Linux kernel, the
following vulnerability has been resolved:
intel_th: fix device leak on output open() Make
sure to drop the reference taken when looking up
the th device during output device open() on
errors and on close(). Note that a recent commit
fixed the leak in a couple of open() error paths
but not all of them, and the reference is still
leaking on successful open(). |
| CVE-2026-23093 |
In the Linux kernel, the
following vulnerability has been resolved: ksmbd:
smbd: fix dma_unmap_sg() nents The dma_unmap_sg()
functions should be called with the same nents as
the dma_map_sg(), not the value the map function
returned. |
| CVE-2026-23094 |
In the Linux kernel, the
following vulnerability has been resolved: uacce:
fix isolate sysfs check condition uacce supports
the device isolation feature. If the driver
implements the isolate_err_threshold_read and
isolate_err_threshold_write callback functions,
uacce will create sysfs files now. Users can read
and configure the isolation policy through sysfs.
Currently, sysfs files are created as long as
either isolate_err_threshold_read or
isolate_err_threshold_write callback functions are
present. However, accessing a non-existent
callback function may cause the system to crash.
Therefore, intercept the creation of sysfs if
neither read nor write exists; create sysfs if
either is supported, but intercept unsupported
operations at the call site. |
| CVE-2026-23095 |
In the Linux kernel, the
following vulnerability has been resolved: gue:
Fix skb memleak with inner IP protocol 0. syzbot
reported skb memleak below. [0] The repro
generated a GUE packet with its inner protocol 0.
gue_udp_recv() returns -guehdr->proto_ctype for
"resubmit" in ip_protocol_deliver_rcu(), but this
only works with non-zero protocol number. Let's
drop such packets. Note that 0 is a valid number
(IPv6 Hop-by-Hop Option). I think it is not
practical to encap HOPOPT in GUE, so once someone
starts to complain, we could pass down a resubmit
flag pointer to distinguish two zeros from the
upper layer: * no error * resubmit HOPOPT [0] BUG:
memory leak unreferenced object 0xffff888109695a00
(size 240): comm "syz.0.17", pid 6088, jiffies
4294943096 hex dump (first 32 bytes): 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
................ 00 40 c2 10 81 88 ff ff 00 00 00
00 00 00 00 00 .@.............. backtrace (crc
a84b336f): kmemleak_alloc_recursive
include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4958 [inline]
slab_alloc_node mm/slub.c:5263 [inline]
kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270
__build_skb+0x23/0x60 net/core/skbuff.c:474
build_skb+0x20/0x190 net/core/skbuff.c:490
__tun_build_skb drivers/net/tun.c:1541 [inline]
tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636
tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770
tun_chr_write_iter+0x71/0x120
drivers/net/tun.c:1999 new_sync_write
fs/read_write.c:593 [inline] vfs_write+0x45d/0x710
fs/read_write.c:686 ksys_write+0xa7/0x170
fs/read_write.c:738 do_syscall_x64
arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xa4/0xf80
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
| CVE-2026-23096 |
In the Linux kernel, the
following vulnerability has been resolved: uacce:
fix cdev handling in the cleanup path When
cdev_device_add fails, it internally releases the
cdev memory, and if cdev_device_del is then
executed, it will cause a hang error. To fix it,
we check the return value of cdev_device_add() and
clear uacce->cdev to avoid calling
cdev_device_del in the uacce_remove. |
| CVE-2026-23097 |
In the Linux kernel, the
following vulnerability has been resolved:
migrate: correct lock ordering for hugetlb file
folios Syzbot has found a deadlock (analyzed by
Lance Yang): 1) Task (5749): Holds folio_lock,
then tries to acquire i_mmap_rwsem(read lock). 2)
Task (5754): Holds i_mmap_rwsem(write lock), then
tries to acquire folio_lock. migrate_pages() ->
migrate_hugetlbs() ->
unmap_and_move_huge_page() <- Takes folio_lock!
-> remove_migration_ptes() ->
__rmap_walk_file() -> i_mmap_lock_read() <-
Waits for i_mmap_rwsem(read lock)!
hugetlbfs_fallocate() -> hugetlbfs_punch_hole()
<- Takes i_mmap_rwsem(write lock)! ->
hugetlbfs_zero_partial_page() ->
filemap_lock_hugetlb_folio() ->
filemap_lock_folio() -> __filemap_get_folio
<- Waits for folio_lock! The migration path is
the one taking locks in the wrong order according
to the documentation at the top of mm/rmap.c. So
expand the scope of the existing i_mmap_lock to
cover the calls to remove_migration_ptes() too.
This is (mostly) how it used to be after commit
c0d0381ade79. That was removed by 336bf30eb765 for
both file & anon hugetlb pages when it should
only have been removed for anon hugetlb
pages. |
| CVE-2026-23098 |
In the Linux kernel, the
following vulnerability has been resolved: netrom:
fix double-free in nr_route_frame() In
nr_route_frame(), old_skb is immediately freed
without checking if nr_neigh->ax25 pointer is
NULL. Therefore, if nr_neigh->ax25 is NULL, the
caller function will free old_skb again, causing a
double-free bug. Therefore, to prevent this, we
need to modify it to check whether
nr_neigh->ax25 is NULL before freeing
old_skb. |
| CVE-2026-23099 |
In the Linux kernel, the
following vulnerability has been resolved:
bonding: limit BOND_MODE_8023AD to Ethernet
devices BOND_MODE_8023AD makes sense for
ARPHRD_ETHER only. syzbot reported: BUG: KASAN:
global-out-of-bounds in __hw_addr_create
net/core/dev_addr_lists.c:63 [inline] BUG: KASAN:
global-out-of-bounds in
__hw_addr_add_ex+0x25d/0x760
net/core/dev_addr_lists.c:118 Read of size 16 at
addr ffffffff8bf94040 by task syz.1.3580/19497
CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted:
G L syzkaller #0 PREEMPT(full) Tainted:
[L]=SOFTLOCKUP Hardware name: Google Google
Compute Engine/Google Compute Engine, BIOS Google
10/25/2025 Call Trace: <TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378
[inline] print_report+0xca/0x240
mm/kasan/report.c:482 kasan_report+0x118/0x150
mm/kasan/report.c:595 check_region_inline
mm/kasan/generic.c:-1 [inline]
kasan_check_range+0x2b0/0x2c0
mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70
mm/kasan/shadow.c:105 __hw_addr_create
net/core/dev_addr_lists.c:63 [inline]
__hw_addr_add_ex+0x25d/0x760
net/core/dev_addr_lists.c:118 __dev_mc_add
net/core/dev_addr_lists.c:868 [inline]
dev_mc_add+0xa1/0x120
net/core/dev_addr_lists.c:886
bond_enslave+0x2b8b/0x3ac0
drivers/net/bonding/bond_main.c:2180
do_set_master+0x533/0x6d0
net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0
net/core/rtnetlink.c:3165 rtnl_changelink
net/core/rtnetlink.c:3776 [inline] __rtnl_newlink
net/core/rtnetlink.c:3935 [inline]
rtnl_newlink+0x161c/0x1c90
net/core/rtnetlink.c:4072
rtnetlink_rcv_msg+0x7cf/0xb70
net/core/rtnetlink.c:6958
netlink_rcv_skb+0x208/0x470
net/netlink/af_netlink.c:2550
netlink_unicast_kernel
net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x82f/0x9e0
net/netlink/af_netlink.c:1344
netlink_sendmsg+0x805/0xb30
net/netlink/af_netlink.c:1894 sock_sendmsg_nosec
net/socket.c:727 [inline]
__sock_sendmsg+0x21c/0x270 net/socket.c:742
____sys_sendmsg+0x505/0x820 net/socket.c:2592
___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646
__sys_sendmsg+0x164/0x220 net/socket.c:2678
do_syscall_32_irqs_on
arch/x86/entry/syscall_32.c:83 [inline]
__do_fast_syscall_32+0x1dc/0x560
arch/x86/entry/syscall_32.c:307
do_fast_syscall_32+0x34/0x80
arch/x86/entry/syscall_32.c:332
entry_SYSENTER_compat_after_hwframe+0x84/0x8e
</TASK> The buggy address belongs to the
variable: lacpdu_mcast_addr+0x0/0x40 |
| CVE-2026-23101 |
In the Linux kernel, the
following vulnerability has been resolved: leds:
led-class: Only Add LED to leds_list when it is
fully ready Before this change the LED was added
to leds_list before led_init_core() gets called
adding it the list before
led_classdev.set_brightness_work gets initialized.
This leaves a window where led_trigger_register()
of a LED's default trigger will call
led_trigger_set() which calls led_set_brightness()
which in turn will end up queueing the
*uninitialized* led_classdev.set_brightness_work.
This race gets hit by the lenovo-thinkpad-t14s EC
driver which registers 2 LEDs with a default
trigger provided by snd_ctl_led.ko in quick
succession. The first led_classdev_register()
causes an async modprobe of snd_ctl_led to run and
that async modprobe manages to exactly hit the
window where the second LED is on the leds_list
without led_init_core() being called for it,
resulting in: ------------[ cut here ]------------
WARNING: CPU: 11 PID: 5608 at
kernel/workqueue.c:4234 __flush_work+0x344/0x390
Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS
N42ET93W (2.23 ) 09/01/2025 ... Call trace:
__flush_work+0x344/0x390 (P) flush_work+0x2c/0x50
led_trigger_set+0x1c8/0x340
led_trigger_register+0x17c/0x1c0
led_trigger_register_simple+0x84/0xe8
snd_ctl_led_init+0x40/0xf88 [snd_ctl_led]
do_one_initcall+0x5c/0x318
do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998
Close the race window by moving the adding of the
LED to leds_list to after the led_init_core()
call. |
| CVE-2026-23102 |
In the Linux kernel, the
following vulnerability has been resolved:
arm64/fpsimd: signal: Fix restoration of SVE
context When SME is supported, Restoring SVE
signal context can go wrong in a few ways,
including placing the task into an invalid state
where the kernel may read from out-of-bounds
memory (and may potentially take a fatal fault)
and/or may kill the task with a SIGKILL. (1)
Restoring a context with SVE_SIG_FLAG_SM set can
place the task into an invalid state where SVCR.SM
is set (and sve_state is non-NULL) but TIF_SME is
clear, consequently resuting in out-of-bounds
memory reads and/or killing the task with SIGKILL.
This can only occur in unusual (but legitimate)
cases where the SVE signal context has either been
modified by userspace or was saved in the context
of another task (e.g. as with CRIU), as otherwise
the presence of an SVE signal context with
SVE_SIG_FLAG_SM implies that TIF_SME is already
set. While in this state, task_fpsimd_load() will
NOT configure SMCR_ELx (leaving some arbitrary
value configured in hardware) before restoring
SVCR and attempting to restore the streaming mode
SVE registers from memory via sve_load_state(). As
the value of SMCR_ELx.LEN may be larger than the
task's streaming SVE vector length, this may read
memory outside of the task's allocated sve_state,
reading unrelated data and/or triggering a fault.
While this can result in secrets being loaded into
streaming SVE registers, these values are never
exposed. As TIF_SME is clear,
fpsimd_bind_task_to_cpu() will configure
CPACR_ELx.SMEN to trap EL0 accesses to streaming
mode SVE registers, so these cannot be accessed
directly at EL0. As fpsimd_save_user_state()
verifies the live vector length before saving
(S)SVE state to memory, no secret values can be
saved back to memory (and hence cannot be observed
via ptrace, signals, etc). When the live vector
length doesn't match the expected vector length
for the task, fpsimd_save_user_state() will send a
fatal SIGKILL signal to the task. Hence the task
may be killed after executing userspace for some
period of time. (2) Restoring a context with
SVE_SIG_FLAG_SM clear does not clear the task's
SVCR.SM. If SVCR.SM was set prior to restoring the
context, then the task will be left in streaming
mode unexpectedly, and some register state will be
combined inconsistently, though the task will be
left in legitimate state from the kernel's PoV.
This can only occur in unusual (but legitimate)
cases where ptrace has been used to set SVCR.SM
after entry to the sigreturn syscall, as syscall
entry clears SVCR.SM. In these cases, the the
provided SVE register data will be loaded into the
task's sve_state using the non-streaming SVE
vector length and the FPSIMD registers will be
merged into this using the streaming SVE vector
length. Fix (1) by setting TIF_SME when setting
SVCR.SM. This also requires ensuring that the
task's sme_state has been allocated, but as this
could contain live ZA state, it should not be
zeroed. Fix (2) by clearing SVCR.SM when restoring
a SVE signal context with SVE_SIG_FLAG_SM clear.
For consistency, I've pulled the manipulation of
SVCR, TIF_SVE, TIF_SME, and fp_type earlier,
immediately after the allocation of
sve_state/sme_state, before the restore of the
actual register state. This makes it easier to
ensure that these are always modified
consistently, even if a fault is taken while
reading the register data from the signal context.
I do not expect any software to depend on the
exact state restored when a fault is taken while
reading the context. |
| CVE-2026-23103 |
In the Linux kernel, the
following vulnerability has been resolved: ipvlan:
Make the addrs_lock be per port Make the
addrs_lock be per port, not per ipvlan dev.
Initial code seems to be written in the
assumption, that any address change must occur
under RTNL. But it is not so for the case of IPv6.
So 1) Introduce per-port addrs_lock. 2) It was
needed to fix places where it was forgotten to
take lock (ipvlan_open/ipvlan_close) This appears
to be a very minor problem though. Since it's
highly unlikely that ipvlan_add_addr() will be
called on 2 CPU simultaneously. But nevertheless,
this could cause: 1) False-negative of
ipvlan_addr_busy(): one interface iterated through
all port->ipvlans + ipvlan->addrs under some
ipvlan spinlock, and another added IP under its
own lock. Though this is only possible for IPv6,
since looks like only ipvlan_addr6_event() can be
called without rtnl_lock. 2) Race since
ipvlan_ht_addr_add(port) is called under different
ipvlan->addrs_lock locks This should not affect
performance, since add/remove IP is a rare
situation and spinlock is not taken on fast
paths. |
| CVE-2026-23105 |
In the Linux kernel, the
following vulnerability has been resolved:
net/sched: qfq: Use cl_is_active to determine
whether class is active in qfq_rm_from_ag This is
more of a preventive patch to make the code more
consistent and to prevent possible exploits that
employ child qlen manipulations on qfq. use
cl_is_active instead of relying on the child
qdisc's qlen to determine class
activation. |
| CVE-2026-23107 |
In the Linux kernel, the
following vulnerability has been resolved:
arm64/fpsimd: signal: Allocate SSVE storage when
restoring ZA The code to restore a ZA context
doesn't attempt to allocate the task's sve_state
before setting TIF_SME. Consequently, restoring a
ZA context can place a task into an invalid state
where TIF_SME is set but the task's sve_state is
NULL. In legitimate but uncommon cases where the
ZA signal context was NOT created by the kernel in
the context of the same task (e.g. if the task is
saved/restored with something like CRIU), we have
no guarantee that sve_state had been allocated
previously. In these cases, userspace can enter
streaming mode without trapping while sve_state is
NULL, causing a later NULL pointer dereference
when the kernel attempts to store the register
state: | # ./sigreturn-za | Unable to handle
kernel NULL pointer dereference at virtual address
0000000000000000 | Mem abort info: | ESR =
0x0000000096000046 | EC = 0x25: DABT (current EL),
IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW =
0 | FSC = 0x06: level 2 translation fault | Data
abort info: | ISV = 0, ISS = 0x00000046, ISS2 =
0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess =
0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 |
user pgtable: 4k pages, 52-bit VAs,
pgdp=0000000101f47c00 | [0000000000000000]
pgd=08000001021d8403, p4d=0800000102274403,
pud=0800000102275403, pmd=0000000000000000 |
Internal error: Oops: 0000000096000046 [#1] SMP |
Modules linked in: | CPU: 0 UID: 0 PID: 153 Comm:
sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT |
Hardware name: linux,dummy-virt (DT) | pstate:
214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS
BTYPE=--) | pc : sve_save_state+0x4/0xf0 | lr :
fpsimd_save_user_state+0xb0/0x1c0 | sp :
ffff80008070bcc0 | x29: ffff80008070bcc0 x28:
fff00000c1ca4c40 x27: 63cfa172fb5cf658 | x26:
fff00000c1ca5228 x25: 0000000000000000 x24:
0000000000000000 | x23: 0000000000000000 x22:
fff00000c1ca4c40 x21: fff00000c1ca4c40 | x20:
0000000000000020 x19: fff00000ff6900f0 x18:
0000000000000000 | x17: fff05e8e0311f000 x16:
0000000000000000 x15: 028fca8f3bdaf21c | x14:
0000000000000212 x13: fff00000c0209f10 x12:
0000000000000020 | x11: 0000000000200b20 x10:
0000000000000000 x9 : fff00000ff69dcc0 | x8 :
00000000000003f2 x7 : 0000000000000001 x6 :
fff00000c1ca5b48 | x5 : fff05e8e0311f000 x4 :
0000000008000000 x3 : 0000000000000000 | x2 :
0000000000000001 x1 : fff00000c1ca5970 x0 :
0000000000000440 | Call trace: |
sve_save_state+0x4/0xf0 (P) |
fpsimd_thread_switch+0x48/0x198 |
__switch_to+0x20/0x1c0 | __schedule+0x36c/0xce0 |
schedule+0x34/0x11c |
exit_to_user_mode_loop+0x124/0x188 |
el0_interrupt+0xc8/0xd8 |
__el0_irq_handler_common+0x18/0x24 |
el0t_64_irq_handler+0x10/0x1c |
el0t_64_irq+0x198/0x19c | Code: 54000040 d51b4408
d65f03c0 d503245f (e5bb5800) | ---[ end trace
0000000000000000 ]--- Fix this by having
restore_za_context() ensure that the task's
sve_state is allocated, matching what we do when
taking an SME trap. Any live SVE/SSVE state (which
is restored earlier from a separate signal
context) must be preserved, and hence this is not
zeroed. |
| CVE-2026-23108 |
In the Linux kernel, the
following vulnerability has been resolved: can:
usb_8dev: usb_8dev_read_bulk_callback(): fix URB
memory leak Fix similar memory leak as in commit
7352e1d5932a ("can: gs_usb:
gs_usb_receive_bulk_callback(): fix URB memory
leak"). In usb_8dev_open() -> usb_8dev_start(),
the URBs for USB-in transfers are allocated, added
to the priv->rx_submitted anchor and submitted.
In the complete callback
usb_8dev_read_bulk_callback(), the URBs are
processed and resubmitted. In usb_8dev_close()
-> unlink_all_urbs() the URBs are freed by
calling
usb_kill_anchored_urbs(&priv->rx_submitted).
However, this does not take into account that the
USB framework unanchors the URB before the
complete function is called. This means that once
an in-URB has been completed, it is no longer
anchored and is ultimately not released in
usb_kill_anchored_urbs(). Fix the memory leak by
anchoring the URB in the
usb_8dev_read_bulk_callback() to the
priv->rx_submitted anchor. |
| CVE-2026-23110 |
In the Linux kernel, the
following vulnerability has been resolved: scsi:
core: Wake up the error handler when final
completions race against each other The fragile
ordering between marking commands completed or
failed so that the error handler only wakes when
the last running command completes or times out
has race conditions. These race conditions can
cause the SCSI layer to fail to wake the error
handler, leaving I/O through the SCSI host stuck
as the error state cannot advance. First, there is
an memory ordering issue within
scsi_dec_host_busy(). The write which clears
SCMD_STATE_INFLIGHT may be reordered with reads
counting in scsi_host_busy(). While the local CPU
will see its own write, reordering can allow other
CPUs in scsi_dec_host_busy() or
scsi_eh_inc_host_failed() to see a raised busy
count, causing no CPU to see a host busy equal to
the host_failed count. This race condition can be
prevented with a memory barrier on the error path
to force the write to be visible before counting
host busy commands. Second, there is a general
ordering issue with scsi_eh_inc_host_failed(). By
counting busy commands before incrementing
host_failed, it can race with a final command in
scsi_dec_host_busy(), such that
scsi_dec_host_busy() does not see host_failed
incremented but scsi_eh_inc_host_failed() counts
busy commands before SCMD_STATE_INFLIGHT is
cleared by scsi_dec_host_busy(), resulting in
neither waking the error handler task. This needs
the call to scsi_host_busy() to be moved after
host_failed is incremented to close the race
condition. |
| CVE-2026-23112 |
In the Linux kernel, the
following vulnerability has been resolved:
nvmet-tcp: add bounds checks in
nvmet_tcp_build_pdu_iovec
nvmet_tcp_build_pdu_iovec() could walk past
cmd->req.sg when a PDU length or offset exceeds
sg_cnt and then use bogus sg->length/offset
values, leading to _copy_to_iter() GPF/KASAN.
Guard sg_idx, remaining entries, and
sg->length/offset before building the
bvec. |
| CVE-2026-23113 |
In the Linux kernel, the
following vulnerability has been resolved:
io_uring/io-wq: check IO_WQ_BIT_EXIT inside work
run loop Currently this is checked before running
the pending work. Normally this is quite fine, as
work items either end up blocking (which will
create a new worker for other items), or they
complete fairly quickly. But syzbot reports an
issue where io-wq takes seemingly forever to exit,
and with a bit of debugging, this turns out to be
because it queues a bunch of big (2GB - 4096b)
reads with a /dev/msr* file. Since this file type
doesn't support ->read_iter(), loop_rw_iter()
ends up handling them. Each read returns 16MB of
data read, which takes 20 (!!) seconds. With a
bunch of these pending, processing the whole chain
can take a long time. Easily longer than the
syzbot uninterruptible sleep timeout of 140
seconds. This then triggers a complaint off the
io-wq exit path: INFO: task syz.4.135:6326 blocked
for more than 143 seconds. Not tainted syzkaller
#0 Blocked by coredump. "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables
this message. task:syz.4.135 state:D stack:26824
pid:6326 tgid:6324 ppid:5957 task_flags:0x400548
flags:0x00080000 Call Trace: <TASK>
context_switch kernel/sched/core.c:5256 [inline]
__schedule+0x1139/0x6150 kernel/sched/core.c:6863
__schedule_loop kernel/sched/core.c:6945 [inline]
schedule+0xe7/0x3a0 kernel/sched/core.c:6960
schedule_timeout+0x257/0x290
kernel/time/sleep_timeout.c:75 do_wait_for_common
kernel/sched/completion.c:100 [inline]
__wait_for_common+0x2fc/0x4e0
kernel/sched/completion.c:121 io_wq_exit_workers
io_uring/io-wq.c:1328 [inline]
io_wq_put_and_exit+0x271/0x8a0
io_uring/io-wq.c:1356
io_uring_clean_tctx+0x10d/0x190
io_uring/tctx.c:203
io_uring_cancel_generic+0x69c/0x9a0
io_uring/cancel.c:651 io_uring_files_cancel
include/linux/io_uring.h:19 [inline]
do_exit+0x2ce/0x2bd0 kernel/exit.c:911
do_group_exit+0xd3/0x2a0 kernel/exit.c:1112
get_signal+0x2671/0x26d0 kernel/signal.c:3034
arch_do_signal_or_restart+0x8f/0x7e0
arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:41
[inline] exit_to_user_mode_loop+0x8c/0x540
kernel/entry/common.c:75
__exit_to_user_mode_prepare
include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare
include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode_work
include/linux/entry-common.h:159 [inline]
syscall_exit_to_user_mode
include/linux/entry-common.h:194 [inline]
do_syscall_64+0x4ee/0xf80
arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:
0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8
EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX:
fffffffffffffe00 RBX: 00007fa0275e6098 RCX:
00007fa02738f749 RDX: 0000000000000000 RSI:
0000000000000080 RDI: 00007fa0275e6098 RBP:
00007fa0275e6090 R08: 0000000000000000 R09:
0000000000000000 R10: 0000000000000000 R11:
0000000000000246 R12: 0000000000000000 R13:
00007fa0275e6128 R14: 00007fff14e4fcb0 R15:
00007fff14e4fd98 There's really nothing wrong
here, outside of processing these reads will take
a LONG time. However, we can speed up the exit by
checking the IO_WQ_BIT_EXIT inside the
io_worker_handle_work() loop, as syzbot will exit
the ring after queueing up all of these reads.
Then once the first item is processed, io-wq will
simply cancel the rest. That should avoid syzbot
running into this complaint again. |
| CVE-2026-23116 |
In the Linux kernel, the
following vulnerability has been resolved:
pmdomain: imx8m-blk-ctrl: Remove separate rst and
clk mask for 8mq vpu For i.MX8MQ platform, the ADB
in the VPUMIX domain has no separate reset and
clock enable bits, but is ungated and reset
together with the VPUs. So we can't reset G1 or G2
separately, it may led to the system hang. Remove
rst_mask and clk_mask of
imx8mq_vpu_blk_ctl_domain_data. Let
imx8mq_vpu_power_notifier() do really vpu
reset. |
| CVE-2026-23119 |
In the Linux kernel, the
following vulnerability has been resolved:
bonding: provide a net pointer to
__skb_flow_dissect() After 3cbf4ffba5ee ("net:
plumb network namespace into __skb_flow_dissect")
we have to provide a net pointer to
__skb_flow_dissect(), either via skb->dev,
skb->sk, or a user provided pointer. In the
following case, syzbot was able to cook a bare
skb. WARNING: net/core/flow_dissector.c:1131 at
__skb_flow_dissect+0xb57/0x68b0
net/core/flow_dissector.c:1131, CPU#1:
syz.2.1418/11053 Call Trace: <TASK>
bond_flow_dissect
drivers/net/bonding/bond_main.c:4093 [inline]
__bond_xmit_hash+0x2d7/0xba0
drivers/net/bonding/bond_main.c:4157
bond_xmit_hash_xdp
drivers/net/bonding/bond_main.c:4208 [inline]
bond_xdp_xmit_3ad_xor_slave_get
drivers/net/bonding/bond_main.c:5139 [inline]
bond_xdp_get_xmit_slave+0x1fd/0x710
drivers/net/bonding/bond_main.c:5515
xdp_master_redirect+0x13f/0x2c0
net/core/filter.c:4388 bpf_prog_run_xdp
include/net/xdp.h:700 [inline]
bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421
bpf_prog_test_run_xdp+0x795/0x10e0
net/bpf/test_run.c:1390
bpf_prog_test_run+0x2c7/0x340
kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860
kernel/bpf/syscall.c:6182 __do_sys_bpf
kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf
kernel/bpf/syscall.c:6272 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xec/0xf80
arch/x86/entry/syscall_64.c:94 |
| CVE-2026-23120 |
In the Linux kernel, the
following vulnerability has been resolved: l2tp:
avoid one data-race in l2tp_tunnel_del_work() We
should read sk->sk_socket only when dealing
with kernel sockets. syzbot reported the following
data-race: BUG: KCSAN: data-race in
l2tp_tunnel_del_work / sk_common_release write to
0xffff88811c182b20 of 8 bytes by task 5365 on cpu
0: sk_set_socket include/net/sock.h:2092 [inline]
sock_orphan include/net/sock.h:2118 [inline]
sk_common_release+0xae/0x230 net/core/sock.c:4003
udp_lib_close+0x15/0x20 include/net/udp.h:325
inet_release+0xce/0xf0 net/ipv4/af_inet.c:437
__sock_release net/socket.c:662 [inline]
sock_close+0x6b/0x150 net/socket.c:1455
__fput+0x29b/0x650 fs/file_table.c:468
____fput+0x1c/0x30 fs/file_table.c:496
task_work_run+0x131/0x1a0 kernel/task_work.c:233
resume_user_mode_work
include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:44
[inline] exit_to_user_mode_loop+0x1fe/0x740
kernel/entry/common.c:75
__exit_to_user_mode_prepare
include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare
include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode_work
include/linux/entry-common.h:159 [inline]
syscall_exit_to_user_mode
include/linux/entry-common.h:194 [inline]
do_syscall_64+0x1e1/0x2b0
arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f read to
0xffff88811c182b20 of 8 bytes by task 827 on cpu
1: l2tp_tunnel_del_work+0x2f/0x1a0
net/l2tp/l2tp_core.c:1418 process_one_work
kernel/workqueue.c:3257 [inline]
process_scheduled_works+0x4ce/0x9d0
kernel/workqueue.c:3340 worker_thread+0x582/0x770
kernel/workqueue.c:3421 kthread+0x489/0x510
kernel/kthread.c:463 ret_from_fork+0x149/0x290
arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30
arch/x86/entry/entry_64.S:246 value changed:
0xffff88811b818000 ->
0x0000000000000000 |
| CVE-2026-23121 |
In the Linux kernel, the
following vulnerability has been resolved: mISDN:
annotate data-race around dev->work
dev->work can re read locklessly in
mISDN_read() and mISDN_poll(). Add
READ_ONCE()/WRITE_ONCE() annotations. BUG: KCSAN:
data-race in mISDN_ioctl / mISDN_read write to
0xffff88812d848280 of 4 bytes by task 10864 on cpu
1: misdn_add_timer
drivers/isdn/mISDN/timerdev.c:175 [inline]
mISDN_ioctl+0x2fb/0x550
drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl
fs/ioctl.c:51 [inline] __do_sys_ioctl
fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140
fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50
fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000
arch/x86/include/generated/asm/syscalls_64.h:17
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xd8/0x2c0
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f read to
0xffff88812d848280 of 4 bytes by task 10857 on cpu
0: mISDN_read+0x1f2/0x470
drivers/isdn/mISDN/timerdev.c:112
do_loop_readv_writev fs/read_write.c:847 [inline]
vfs_readv+0x3fb/0x690 fs/read_write.c:1020
do_readv+0xe7/0x210 fs/read_write.c:1080
__do_sys_readv fs/read_write.c:1165 [inline]
__se_sys_readv fs/read_write.c:1162 [inline]
__x64_sys_readv+0x45/0x50 fs/read_write.c:1162
x64_sys_call+0x2831/0x3000
arch/x86/include/generated/asm/syscalls_64.h:20
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xd8/0x2c0
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f value
changed: 0x00000000 -> 0x00000001 |
| CVE-2026-23123 |
In the Linux kernel, the
following vulnerability has been resolved:
interconnect: debugfs: initialize src_node and
dst_node to empty strings The debugfs_create_str()
API assumes that the string pointer is either NULL
or points to valid kmalloc() memory. Leaving the
pointer uninitialized can cause problems.
Initialize src_node and dst_node to empty strings
before creating the debugfs entries to guarantee
that reads and writes are safe. |
| CVE-2026-23124 |
In the Linux kernel, the
following vulnerability has been resolved: ipv6:
annotate data-race in ndisc_router_discovery()
syzbot found that ndisc_router_discovery() could
read and write in6_dev->ra_mtu without holding
a lock [1] This looks fine, IFLA_INET6_RA_MTU is
best effort. Add READ_ONCE()/WRITE_ONCE() to
document the race. Note that we might also reject
illegal MTU values (mtu < IPV6_MIN_MTU || mtu
> skb->dev->mtu) in a future patch. [1]
BUG: KCSAN: data-race in ndisc_router_discovery /
ndisc_router_discovery read to 0xffff888119809c20
of 4 bytes by task 25817 on cpu 1:
ndisc_router_discovery+0x151d/0x1c90
net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0
net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0
net/ipv6/icmp.c:989
ip6_protocol_deliver_rcu+0xb2a/0x10d0
net/ipv6/ip6_input.c:438
ip6_input_finish+0xf0/0x1d0
net/ipv6/ip6_input.c:489 NF_HOOK
include/linux/netfilter.h:318 [inline]
ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500
ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590
dst_input include/net/dst.h:474 [inline]
ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79
... write to 0xffff888119809c20 of 4 bytes by task
25816 on cpu 0:
ndisc_router_discovery+0x155a/0x1c90
net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0
net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0
net/ipv6/icmp.c:989
ip6_protocol_deliver_rcu+0xb2a/0x10d0
net/ipv6/ip6_input.c:438
ip6_input_finish+0xf0/0x1d0
net/ipv6/ip6_input.c:489 NF_HOOK
include/linux/netfilter.h:318 [inline]
ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500
ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590
dst_input include/net/dst.h:474 [inline]
ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79
... value changed: 0x00000000 ->
0xe5400659 |
| CVE-2026-23125 |
In the Linux kernel, the
following vulnerability has been resolved: sctp:
move SCTP_CMD_ASSOC_SHKEY right after
SCTP_CMD_PEER_INIT A null-ptr-deref was reported
in the SCTP transmit path when SCTP-AUTH key
initialization fails:
==================================================================
KASAN: null-ptr-deref in range
[0x0000000000000018-0x000000000000001f] CPU: 0
PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2
RIP: 0010:sctp_packet_bundle_auth
net/sctp/output.c:264 [inline] RIP:
0010:sctp_packet_append_chunk+0xb36/0x1260
net/sctp/output.c:401 Call Trace:
sctp_packet_transmit_chunk+0x31/0x250
net/sctp/output.c:189
sctp_outq_flush_data+0xa29/0x26d0
net/sctp/outqueue.c:1111
sctp_outq_flush+0xc80/0x1240
net/sctp/outqueue.c:1217
sctp_cmd_interpreter.isra.0+0x19a5/0x62c0
net/sctp/sm_sideeffect.c:1787 sctp_side_effects
net/sctp/sm_sideeffect.c:1198 [inline]
sctp_do_sm+0x1a3/0x670
net/sctp/sm_sideeffect.c:1169
sctp_assoc_bh_rcv+0x33e/0x640
net/sctp/associola.c:1052
sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88
sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243
sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue
is triggered when sctp_auth_asoc_init_active_key()
fails in sctp_sf_do_5_1C_ack() while processing an
INIT_ACK. In this case, the command sequence is
currently: - SCTP_CMD_PEER_INIT -
SCTP_CMD_TIMER_STOP (T1_INIT) -
SCTP_CMD_TIMER_START (T1_COOKIE) -
SCTP_CMD_NEW_STATE (COOKIE_ECHOED) -
SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If
SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains
NULL, while asoc->peer.auth_capable and
asoc->peer.peer_chunks have already been set by
SCTP_CMD_PEER_INIT. This allows a DATA chunk with
auth = 1 and shkey = NULL to be queued by
sctp_datamsg_from_user(). Since command
interpretation stops on failure, no COOKIE_ECHO
should been sent via SCTP_CMD_GEN_COOKIE_ECHO.
However, the T1_COOKIE timer has already been
started, and it may enqueue a COOKIE_ECHO into the
outqueue later. As a result, the DATA chunk can be
transmitted together with the COOKIE_ECHO in
sctp_outq_flush_data(), leading to the observed
issue. Similar to the other places where it calls
sctp_auth_asoc_init_active_key() right after
sctp_process_init(), this patch moves the
SCTP_CMD_ASSOC_SHKEY immediately after
SCTP_CMD_PEER_INIT, before stopping T1_INIT and
starting T1_COOKIE. This ensures that if shared
key generation fails, authenticated DATA cannot be
sent. It also allows the T1_INIT timer to
retransmit INIT, giving the client another chance
to process INIT_ACK and retry key setup. |
| CVE-2026-23126 |
In the Linux kernel, the
following vulnerability has been resolved:
netdevsim: fix a race issue related to the
operation on bpf_bound_progs list The netdevsim
driver lacks a protection mechanism for operations
on the bpf_bound_progs list. When the
nsim_bpf_create_prog() performs list_add_tail, it
is possible that nsim_bpf_destroy_prog() is
simultaneously performs list_del. Concurrent
operations on the list may lead to list corruption
and trigger a kernel crash as follows: [
417.290971] kernel BUG at lib/list_debug.c:62! [
417.290983] invalid opcode: 0000 [#1] PREEMPT SMP
NOPTI [ 417.290992] CPU: 10 PID: 168 Comm:
kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5
#1 [ 417.291003] Hardware name: QEMU Standard PC
(Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2
04/01/2014 [ 417.291007] Workqueue: events
bpf_prog_free_deferred [ 417.291021] RIP:
0010:__list_del_entry_valid_or_report+0xa7/0xc0 [
417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48
c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48
89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff
<0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89
f2 48 89 c6 e8 c2 fb a8 [ 417.291040] RSP:
0018:ffffb16a40807df8 EFLAGS: 00010246 [
417.291046] RAX: 000000000000006d RBX:
ffff8e589866f500 RCX: 0000000000000000 [
417.291051] RDX: 0000000000000000 RSI:
ffff8e59f7b23180 RDI: ffff8e59f7b23180 [
417.291055] RBP: ffffb16a412c9000 R08:
0000000000000000 R09: 0000000000000003 [
417.291059] R10: ffffb16a40807c80 R11:
ffffffffaf9edce8 R12: ffff8e594427ac20 [
417.291063] R13: ffff8e59f7b44780 R14:
ffff8e58800b7a05 R15: 0000000000000000 [
417.291074] FS: 0000000000000000(0000)
GS:ffff8e59f7b00000(0000) knlGS:0000000000000000 [
417.291079] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 [ 417.291083] CR2:
00007fc4083efe08 CR3: 00000001c3626006 CR4:
0000000000770ee0 [ 417.291088] PKRU: 55555554 [
417.291091] Call Trace: [ 417.291096] <TASK>
[ 417.291103] nsim_bpf_destroy_prog+0x31/0x80
[netdevsim] [ 417.291154]
__bpf_prog_offload_destroy+0x2a/0x80 [ 417.291163]
bpf_prog_dev_bound_destroy+0x6f/0xb0 [ 417.291171]
bpf_prog_free_deferred+0x18e/0x1a0 [ 417.291178]
process_one_work+0x18a/0x3a0 [ 417.291188]
worker_thread+0x27b/0x3a0 [ 417.291197] ?
__pfx_worker_thread+0x10/0x10 [ 417.291207]
kthread+0xe5/0x120 [ 417.291214] ?
__pfx_kthread+0x10/0x10 [ 417.291221]
ret_from_fork+0x31/0x50 [ 417.291230] ?
__pfx_kthread+0x10/0x10 [ 417.291236]
ret_from_fork_asm+0x1a/0x30 [ 417.291246]
</TASK> Add a mutex lock, to prevent
simultaneous addition and deletion operations on
the list. |
| CVE-2026-23128 |
In the Linux kernel, the
following vulnerability has been resolved: arm64:
Set __nocfi on swsusp_arch_resume() A DABT is
reported[1] on an android based system when resume
from hiberate. This happens because
swsusp_arch_suspend_exit() is marked with
SYM_CODE_*() and does not have a CFI hash, but
swsusp_arch_resume() will attempt to verify the
CFI hash when calling a copy of
swsusp_arch_suspend_exit(). Given that there's an
existing requirement that the entrypoint to
swsusp_arch_suspend_exit() is the first byte of
the .hibernate_exit.text section, we cannot fix
this by marking swsusp_arch_suspend_exit() with
SYM_FUNC_*(). The simplest fix for now is to
disable the CFI check in swsusp_arch_resume().
Mark swsusp_arch_resume() as __nocfi to disable
the CFI check. [1] [ 22.991934][ T1] Unable to
handle kernel paging request at virtual address
0000000109170ffc [ 22.991934][ T1] Mem abort info:
[ 22.991934][ T1] ESR = 0x0000000096000007 [
22.991934][ T1] EC = 0x25: DABT (current EL), IL =
32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [
22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][
T1] FSC = 0x07: level 3 translation fault [
22.991934][ T1] Data abort info: [ 22.991934][ T1]
ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [
22.991934][ T1] CM = 0, WnR = 0, TnD = 0,
TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay =
0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1]
[0000000109170ffc] user address but active_mm is
swapper [ 22.991934][ T1] Internal error: Oops:
0000000096000007 [#1] PREEMPT SMP [ 22.991934][
T1] Dumping ftrace buffer: [ 22.991934][ T1]
(ftrace buffer empty) [ 22.991934][ T1] Modules
linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm:
swapper/0 Not tainted
6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1
688c7060a825a3ac418fe53881730b355915a419 [
22.991934][ T1] Hardware name: Unisoc UMS9360-base
Board (DT) [ 22.991934][ T1] pstate: 804000c5
(Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [
22.991934][ T1] pc :
swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1]
lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][
T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29:
ffffffc08006b9c0 x28: 0000000000000000 x27:
0000000000000000 [ 22.991934][ T1] x26:
0000000000000000 x25: 0000000000000000 x24:
0000000000000820 [ 22.991934][ T1] x23:
ffffffd0817e3000 x22: ffffffd0817e3000 x21:
0000000000000000 [ 22.991934][ T1] x20:
ffffff8089171000 x19: ffffffd08252c8c8 x18:
ffffffc080061058 [ 22.991934][ T1] x17:
00000000529c6ef0 x16: 00000000529c6ef0 x15:
0000000000000004 [ 22.991934][ T1] x14:
ffffff8178c88000 x13: 0000000000000006 x12:
0000000000000000 [ 22.991934][ T1] x11:
0000000000000015 x10: 0000000000000001 x9 :
ffffffd082533000 [ 22.991934][ T1] x8 :
0000000109171000 x7 : 205b5d3433393139 x6 :
392e32322020205b [ 22.991934][ T1] x5 :
000000010916f000 x4 : 000000008164b000 x3 :
ffffff808a4e0530 [ 22.991934][ T1] x2 :
ffffffd08058e784 x1 : 0000000082326000 x0 :
000000010a283000 [ 22.991934][ T1] Call trace: [
22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [
22.991934][ T1] hibernation_restore+0x158/0x18c [
22.991934][ T1] load_image_and_restore+0xb0/0xec [
22.991934][ T1] software_resume+0xf4/0x19c [
22.991934][ T1] software_resume_initcall+0x34/0x78
[ 22.991934][ T1] do_one_initcall+0xe8/0x370 [
22.991934][ T1] do_initcall_level+0xc8/0x19c [
22.991934][ T1] do_initcalls+0x70/0xc0 [
22.991934][ T1] do_basic_setup+0x1c/0x28 [
22.991934][ T1] kernel_init_freeable+0xe0/0x148 [
22.991934][ T1] kernel_init+0x20/0x1a8 [
22.991934][ T1] ret_from_fork+0x10/0x20 [
22.991934][ T1] Code: a9400a61 f94013e0 f9438923
f9400a64 (b85fc110) [catalin.marinas@arm.com:
commit log updated by Mark Rutland] |
| CVE-2026-23129 |
In the Linux kernel, the
following vulnerability has been resolved: dpll:
Prevent duplicate registrations Modify the
internal registration helpers
dpll_xa_ref_{dpll,pin}_add() to reject duplicate
registration attempts. Previously, if a caller
attempted to register the same pin multiple times
(with the same ops, priv, and cookie) on the same
device, the core silently increments the reference
count and return success. This behavior is
incorrect because if the caller makes these
duplicate registrations then for the first one
dpll_pin_registration is allocated and for others
the associated dpll_pin_ref.refcount is
incremented. During the first unregistration the
associated dpll_pin_registration is freed and for
others WARN is fired. Fix this by updating the
logic to return `-EEXIST` if a matching
registration is found to enforce a strict
"register once" policy. |
| CVE-2026-23131 |
In the Linux kernel, the
following vulnerability has been resolved:
platform/x86: hp-bioscfg: Fix kobject warnings for
empty attribute names The hp-bioscfg driver
attempts to register kobjects with empty names
when the HP BIOS returns attributes with empty
name strings. This causes multiple kernel
warnings: kobject: (00000000135fb5e6): attempted
to be registered with empty name! WARNING: CPU: 14
PID: 3336 at lib/kobject.c:219
kobject_add_internal+0x2eb/0x310 Add validation in
hp_init_bios_buffer_attribute() to check if the
attribute name is empty after parsing it from the
WMI buffer. If empty, log a debug message and skip
registration of that attribute, allowing the
module to continue processing other valid
attributes. |
| CVE-2026-23133 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
ath10k: fix dma_free_coherent() pointer
dma_alloc_coherent() allocates a DMA mapped buffer
and stores the addresses in XXX_unaligned fields.
Those should be reused when freeing the buffer
rather than the aligned addresses. |
| CVE-2026-23135 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
ath12k: fix dma_free_coherent() pointer
dma_alloc_coherent() allocates a DMA mapped buffer
and stores the addresses in XXX_unaligned fields.
Those should be reused when freeing the buffer
rather than the aligned addresses. |
| CVE-2026-23136 |
In the Linux kernel, the
following vulnerability has been resolved:
libceph: reset sparse-read state in osd_fault()
When a fault occurs, the connection is abandoned,
reestablished, and any pending operations are
retried. The OSD client tracks the progress of a
sparse-read reply using a separate state machine,
largely independent of the messenger's state. If a
connection is lost mid-payload or the sparse-read
state machine returns an error, the sparse-read
state is not reset. The OSD client will then
interpret the beginning of a new reply as the
continuation of the old one. If this makes the
sparse-read machinery enter a failure state, it
may never recover, producing loops like: libceph:
[0] got 0 extents libceph: data len 142248331 !=
extent len 0 libceph: osd0 (1)...:6801 socket
error on read libceph: data len 142248331 !=
extent len 0 libceph: osd0 (1)...:6801 socket
error on read Therefore, reset the sparse-read
state in osd_fault(), ensuring retries start from
a clean state. |
| CVE-2026-23139 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nf_conncount: update last_gc only when
GC has been performed Currently last_gc is being
updated everytime a new connection is tracked,
that means that it is updated even if a GC wasn't
performed. With a sufficiently high packet rate,
it is possible to always bypass the GC, causing
the list to grow infinitely. Update the last_gc
value only when a GC has been actually
performed. |
| CVE-2026-23140 |
In the Linux kernel, the
following vulnerability has been resolved: bpf,
test_run: Subtract size of xdp_frame from allowed
metadata size The xdp_frame structure takes up
part of the XDP frame headroom, limiting the size
of the metadata. However, in bpf_test_run, we
don't take this into account, which makes it
possible for userspace to supply a metadata size
that is too large (taking up the entire headroom).
If userspace supplies such a large metadata size
in live packet mode, the
xdp_update_frame_from_buff() call in
xdp_test_run_init_page() call will fail, after
which packet transmission proceeds with an
uninitialised frame structure, leading to the
usual Bad Stuff. The commit in the Fixes tag fixed
a related bug where the second check in
xdp_update_frame_from_buff() could fail, but did
not add any additional constraints on the metadata
size. Complete the fix by adding an additional
check on the metadata size. Reorder the checks
slightly to make the logic clearer and add a
comment. |
| CVE-2026-23141 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
send: check for inline extents in
range_is_hole_in_parent() Before accessing the
disk_bytenr field of a file extent item we need to
check if we are dealing with an inline extent.
This is because for inline extents their data
starts at the offset of the disk_bytenr field. So
accessing the disk_bytenr means we are accessing
inline data or in case the inline data is less
than 8 bytes we can actually cause an invalid
memory access if this inline extent item is the
first item in the leaf or access metadata from
other items. |
| CVE-2026-23142 |
In the Linux kernel, the
following vulnerability has been resolved:
mm/damon/sysfs-scheme: cleanup access_pattern
subdirs on scheme dir setup failure When a
DAMOS-scheme DAMON sysfs directory setup fails
after setup of access_pattern/ directory,
subdirectories of access_pattern/ directory are
not cleaned up. As a result, DAMON sysfs interface
is nearly broken until the system reboots, and the
memory for the unremoved directory is leaked.
Cleanup the directories under such
failures. |
| CVE-2026-23144 |
In the Linux kernel, the
following vulnerability has been resolved:
mm/damon/sysfs: cleanup attrs subdirs on context
dir setup failure When a context DAMON sysfs
directory setup is failed after setup of attrs/
directory, subdirectories of attrs/ directory are
not cleaned up. As a result, DAMON sysfs interface
is nearly broken until the system reboots, and the
memory for the unremoved directory is leaked.
Cleanup the directories under such
failures. |
| CVE-2026-23145 |
In the Linux kernel, the
following vulnerability has been resolved: ext4:
fix iloc.bh leak in ext4_xattr_inode_update_ref
The error branch for ext4_xattr_inode_update_ref
forget to release the refcount for iloc.bh. Find
this when review code. |
| CVE-2026-23146 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: hci_uart: fix null-ptr-deref in
hci_uart_write_work hci_uart_set_proto() sets
HCI_UART_PROTO_INIT before calling
hci_uart_register_dev(), which calls
proto->open() to initialize hu->priv.
However, if a TTY write wakeup occurs during this
window, hci_uart_tx_wakeup() may schedule
write_work before hu->priv is initialized,
leading to a NULL pointer dereference in
hci_uart_write_work() when proto->dequeue()
accesses hu->priv. The race condition is: CPU0
CPU1 ---- ---- hci_uart_set_proto()
set_bit(HCI_UART_PROTO_INIT)
hci_uart_register_dev() tty write wakeup
hci_uart_tty_wakeup() hci_uart_tx_wakeup()
schedule_work(&hu->write_work)
proto->open(hu) // initializes hu->priv
hci_uart_write_work() hci_uart_dequeue()
proto->dequeue(hu) // accesses hu->priv
(NULL!) Fix this by moving
set_bit(HCI_UART_PROTO_INIT) after
proto->open() succeeds, ensuring hu->priv is
initialized before any work can be
scheduled. |
| CVE-2026-23148 |
In the Linux kernel, the
following vulnerability has been resolved: nvmet:
fix race in nvmet_bio_done() leading to NULL
pointer dereference There is a race condition in
nvmet_bio_done() that can cause a NULL pointer
dereference in blk_cgroup_bio_start(): 1.
nvmet_bio_done() is called when a bio completes 2.
nvmet_req_complete() is called, which invokes
req->ops->queue_response(req) 3. The
queue_response callback can re-queue and re-submit
the same request 4. The re-submission reuses the
same inline_bio from nvmet_req 5. Meanwhile,
nvmet_req_bio_put() (called after
nvmet_req_complete) invokes bio_uninit() for
inline_bio, which sets bio->bi_blkg to NULL 6.
The re-submitted bio enters
submit_bio_noacct_nocheck() 7.
blk_cgroup_bio_start() dereferences
bio->bi_blkg, causing a crash: BUG: kernel NULL
pointer dereference, address: 0000000000000028
#PF: supervisor read access in kernel mode RIP:
0010:blk_cgroup_bio_start+0x10/0xd0 Call Trace:
submit_bio_noacct_nocheck+0x44/0x250
nvmet_bdev_execute_rw+0x254/0x370 [nvmet]
process_one_work+0x193/0x3c0
worker_thread+0x281/0x3a0 Fix this by reordering
nvmet_bio_done() to call nvmet_req_bio_put()
BEFORE nvmet_req_complete(). This ensures the bio
is cleaned up before the request can be
re-submitted, preventing the race
condition. |
| CVE-2026-23150 |
In the Linux kernel, the
following vulnerability has been resolved: nfc:
llcp: Fix memleak in nfc_llcp_send_ui_frame().
syzbot reported various memory leaks related to
NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc.
[0] The leading log hinted that
nfc_llcp_send_ui_frame() failed to allocate skb
due to sock_error(sk) being -ENXIO. ENXIO is set
by nfc_llcp_socket_release() when struct
nfc_llcp_local is destroyed by local_cleanup().
The problem is that there is no synchronisation
between nfc_llcp_send_ui_frame() and
local_cleanup(), and skb could be put into
local->tx_queue after it was purged in
local_cleanup(): CPU1 CPU2 ---- ----
nfc_llcp_send_ui_frame() local_cleanup() |- do { '
|- pdu = nfc_alloc_send_skb(..., &err) | . |
|- nfc_llcp_socket_release(local, false, ENXIO); |
|- skb_queue_purge(&local->tx_queue); | | '
| |- skb_queue_tail(&local->tx_queue, pdu);
| ... | |- pdu = nfc_alloc_send_skb(..., &err)
| ^._________________________________.'
local_cleanup() is called for struct
nfc_llcp_local only after nfc_llcp_remove_local()
unlinks it from llcp_devices. If we hold
local->tx_queue.lock then, we can synchronise
the thread and nfc_llcp_send_ui_frame(). Let's do
that and check list_empty(&local->list)
before queuing skb to local->tx_queue in
nfc_llcp_send_ui_frame(). [0]: [ 56.074943][
T6096] llcp: nfc_llcp_send_ui_frame: Could not
allocate PDU (error=-6) [ 64.318868][ T5813]
kmemleak: 6 new suspected memory leaks (see
/sys/kernel/debug/kmemleak) BUG: memory leak
unreferenced object 0xffff8881272f6800 (size
1024): comm "syz.0.17", pid 6096, jiffies
4294942766 hex dump (first 32 bytes): 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
................ 27 00 03 40 00 00 00 00 00 00 00
00 00 00 00 00 '..@............ backtrace (crc
da58d84d): kmemleak_alloc_recursive
include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4979 [inline]
slab_alloc_node mm/slub.c:5284 [inline]
__do_kmalloc_node mm/slub.c:5645 [inline]
__kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658
kmalloc_noprof include/linux/slab.h:961 [inline]
sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239
sk_alloc+0x36/0x360 net/core/sock.c:2295
nfc_llcp_sock_alloc+0x37/0x130
net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0
net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0
net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340
net/socket.c:1605 sock_create net/socket.c:1663
[inline] __sys_socket_create net/socket.c:1700
[inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747
__do_sys_socket net/socket.c:1761 [inline]
__se_sys_socket net/socket.c:1759 [inline]
__x64_sys_socket+0x1b/0x30 net/socket.c:1759
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xa4/0xfa0
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG:
memory leak unreferenced object 0xffff88810fbd9800
(size 240): comm "syz.0.17", pid 6096, jiffies
4294942850 hex dump (first 32 bytes): 68 f0 ff 08
81 88 ff ff 68 f0 ff 08 81 88 ff ff
h.......h....... 00 00 00 00 00 00 00 00 00 68 2f
27 81 88 ff ff .........h/'.... backtrace (crc
6cc652b1): kmemleak_alloc_recursive
include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4979 [inline]
slab_alloc_node mm/slub.c:5284 [inline]
kmem_cache_alloc_node_noprof+0x36f/0x5e0
mm/slub.c:5336 __alloc_skb+0x203/0x240
net/core/skbuff.c:660 alloc_skb
include/linux/skbuff.h:1383 [inline]
alloc_skb_with_frags+0x69/0x3f0 net/core/sk
---truncated--- |
| CVE-2026-23151 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: MGMT: Fix memory leak in
set_ssp_complete Fix memory leak in
set_ssp_complete() where mgmt_pending_cmd
structures are not freed after being removed from
the pending list. Commit 302a1f674c00 ("Bluetooth:
MGMT: Fix possible UAFs") replaced
mgmt_pending_foreach() calls with individual
command handling but missed adding
mgmt_pending_free() calls in both error and
success paths of set_ssp_complete(). Other
completion functions like set_le_complete() were
fixed correctly in the same commit. This causes a
memory leak of the mgmt_pending_cmd structure and
its associated parameter data for each SSP command
that completes. Add the missing
mgmt_pending_free(cmd) calls in both code paths to
fix the memory leak. Also fix the same issue in
set_advertising_complete(). |
| CVE-2026-23156 |
In the Linux kernel, the
following vulnerability has been resolved:
efivarfs: fix error propagation in
efivar_entry_get() efivar_entry_get() always
returns success even if the underlying
__efivar_entry_get() fails, masking errors. This
may result in uninitialized heap memory being
copied to userspace in the efivarfs_file_read()
path. Fix it by returning the error from
__efivar_entry_get(). |
| CVE-2026-23159 |
In the Linux kernel, the
following vulnerability has been resolved: perf:
sched: Fix perf crash with new is_user_task()
helper In order to do a user space stacktrace the
current task needs to be a user task that has
executed in user space. It use to be possible to
test if a task is a user task or not by simply
checking the task_struct mm field. If it was non
NULL, it was a user task and if not it was a
kernel task. But things have changed over time,
and some kernel tasks now have their own mm field.
An idea was made to instead test PF_KTHREAD and
two functions were used to wrap this check in case
it became more complex to test if a task was a
user task or not[1]. But this was rejected and the
C code simply checked the PF_KTHREAD directly. It
was later found that not all kernel threads set
PF_KTHREAD. The io-uring helpers instead set
PF_USER_WORKER and this needed to be added as
well. But checking the flags is still not enough.
There's a very small window when a task exits that
it frees its mm field and it is set back to NULL.
If perf were to trigger at this moment, the flags
test would say its a user space task but when perf
would read the mm field it would crash with at
NULL pointer dereference. Now there are flags that
can be used to test if a task is exiting, but they
are set in areas that perf may still want to
profile the user space task (to see where it
exited). The only real test is to check both the
flags and the mm field. Instead of making this
modification in every location, create a new
is_user_task() helper function that does all the
tests needed to know if it is safe to read the
user space memory or not. [1]
https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/ |
| CVE-2026-23160 |
In the Linux kernel, the
following vulnerability has been resolved:
octeon_ep: Fix memory leak in octep_device_setup()
In octep_device_setup(), if octep_ctrl_net_init()
fails, the function returns directly without
unmapping the mapped resources and freeing the
allocated configuration memory. Fix this by
jumping to the unsupported_dev label, which
performs the necessary cleanup. This aligns with
the error handling logic of other paths in this
function. Compile tested only. Issue found using a
prototype static analysis tool and code
review. |
| CVE-2026-23163 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdgpu: fix NULL pointer dereference in
amdgpu_gmc_filter_faults_remove On APUs such as
Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1
and ih2 interrupt ring buffers are not
initialized. This is by design, as these secondary
IH rings are only available on discrete GPUs. See
vega10_ih_sw_init() which explicitly skips ih1/ih2
initialization when AMD_IS_APU is set. However,
amdgpu_gmc_filter_faults_remove() unconditionally
uses ih1 to get the timestamp of the last
interrupt entry. When retry faults are enabled on
APUs (noretry=0), this function is called from the
SVM page fault recovery path, resulting in a NULL
pointer dereference when
amdgpu_ih_decode_iv_ts_helper() attempts to access
ih->ring[]. The crash manifests as: BUG: kernel
NULL pointer dereference, address:
0000000000000004 RIP:
0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40
[amdgpu] Call Trace:
amdgpu_gmc_filter_faults_remove+0x60/0x130
[amdgpu] svm_range_restore_pages+0xae5/0x11c0
[amdgpu] amdgpu_vm_handle_fault+0xc8/0x340
[amdgpu] gmc_v9_0_process_interrupt+0x191/0x220
[amdgpu] amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]
amdgpu_ih_process+0x84/0x100 [amdgpu] This issue
was exposed by commit 1446226d32a4 ("drm/amdgpu:
Remove GC HW IP 9.3.0 from noretry=1") which
changed the default for Renoir APU from noretry=1
to noretry=0, enabling retry fault handling and
thus exercising the buggy code path. Fix this by
adding a check for ih1.ring_size before attempting
to use it. Also restore the soft_ih support from
commit dd299441654f ("drm/amdgpu: Rework retry
fault removal"). This is needed if the hardware
doesn't support secondary HW IH rings. v2:
additional updates (Alex) (cherry picked from
commit
6ce8d536c80aa1f059e82184f0d1994436b1d526) |
| CVE-2026-23164 |
In the Linux kernel, the
following vulnerability has been resolved: rocker:
fix memory leak in rocker_world_port_post_fini()
In rocker_world_port_pre_init(),
rocker_port->wpriv is allocated with
kzalloc(wops->port_priv_size, GFP_KERNEL).
However, in rocker_world_port_post_fini(), the
memory is only freed when wops->port_post_fini
callback is set: if (!wops->port_post_fini)
return; wops->port_post_fini(rocker_port);
kfree(rocker_port->wpriv); Since
rocker_ofdpa_ops does not implement port_post_fini
callback (it is NULL), the wpriv memory allocated
for each port is never freed when ports are
removed. This leads to a memory leak of
sizeof(struct ofdpa_port) bytes per port on every
device removal. Fix this by always calling
kfree(rocker_port->wpriv) regardless of whether
the port_post_fini callback exists. |
| CVE-2026-23166 |
In the Linux kernel, the
following vulnerability has been resolved: ice:
Fix NULL pointer dereference in
ice_vsi_set_napi_queues Add NULL pointer checks in
ice_vsi_set_napi_queues() to prevent crashes
during resume from suspend when
rings[q_idx]->q_vector is NULL. Tested adaptor:
60:00.0 Ethernet controller [0200]: Intel
Corporation Ethernet Controller E810-XXV for SFP
[8086:159b] (rev 02) Subsystem: Intel Corporation
Ethernet Network Adapter E810-XXV-2 [8086:4003]
SR-IOV state: both disabled and enabled can
reproduce this issue. kernel version: v6.18
Reproduce steps: Boot up and execute suspend like
systemctl suspend or rtcwake. Log: <1>[
231.443607] BUG: kernel NULL pointer dereference,
address: 0000000000000040 <1>[ 231.444052]
#PF: supervisor read access in kernel mode
<1>[ 231.444484] #PF: error_code(0x0000) -
not-present page <6>[ 231.444913] PGD 0 P4D
0 <4>[ 231.445342] Oops: Oops: 0000 [#1] SMP
NOPTI <4>[ 231.446635] RIP:
0010:netif_queue_set_napi+0xa/0x170 <4>[
231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f
80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b
<48> 83 79 30 00 0f 84 39 01 00 00 55 41 89
d1 49 89 f8 89 f2 48 89 <4>[ 231.447513]
RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202
<4>[ 231.447961] RAX: ffff8b848ca30400 RBX:
ffff8b848caf2028 RCX: 0000000000000010 <4>[
231.448443] RDX: 0000000000000000 RSI:
0000000000000000 RDI: ffff8b848dbd4000 <4>[
231.448896] RBP: ffffcc780fc078e8 R08:
0000000000000000 R09: 0000000000000000 <4>[
231.449345] R10: 0000000000000000 R11:
0000000000000000 R12: 0000000000000001 <4>[
231.449817] R13: ffff8b848dbd4000 R14:
ffff8b84833390c8 R15: 0000000000000000 <4>[
231.450265] FS: 00007c7b29e9d740(0000)
GS:ffff8b8c068e2000(0000) knlGS:0000000000000000
<4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000
CR0: 0000000080050033 <4>[ 231.451179] CR2:
0000000000000040 CR3: 000000030626f004 CR4:
0000000000f72ef0 <4>[ 231.451629] PKRU:
55555554 <4>[ 231.452076] Call Trace:
<4>[ 231.452549] <TASK> <4>[
231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110
[ice] <4>[ 231.453482] ice_resume+0xfd/0x220
[ice] <4>[ 231.453977] ?
__pfx_pci_pm_resume+0x10/0x10 <4>[
231.454425] pci_pm_resume+0x8c/0x140 <4>[
231.454872] ? __pfx_pci_pm_resume+0x10/0x10
<4>[ 231.455347] dpm_run_callback+0x5f/0x160
<4>[ 231.455796] ?
dpm_wait_for_superior+0x107/0x170 <4>[
231.456244] device_resume+0x177/0x270 <4>[
231.456708] dpm_resume+0x209/0x2f0 <4>[
231.457151] dpm_resume_end+0x15/0x30 <4>[
231.457596] suspend_devices_and_enter+0x1da/0x2b0
<4>[ 231.458054] enter_state+0x10e/0x570 Add
defensive checks for both the ring pointer and its
q_vector before dereferencing, allowing the system
to resume successfully even when q_vectors are
unmapped. |
| CVE-2026-23167 |
In the Linux kernel, the
following vulnerability has been resolved: nfc:
nci: Fix race between rfkill and
nci_unregister_device(). syzbot reported the splat
below [0] without a repro. It indicates that
struct nci_dev.cmd_wq had been destroyed before
nci_close_device() was called via rfkill.
nci_dev.cmd_wq is only destroyed in
nci_unregister_device(), which (I think) was
called from virtual_ncidev_close() when syzbot
close()d an fd of virtual_ncidev. The problem is
that nci_unregister_device() destroys
nci_dev.cmd_wq first and then calls
nfc_unregister_device(), which removes the device
from rfkill by rfkill_unregister(). So, the device
is still visible via rfkill even after
nci_dev.cmd_wq is destroyed. Let's unregister the
device from rfkill first in
nci_unregister_device(). Note that we cannot call
nfc_unregister_device() before nci_close_device()
because 1) nfc_unregister_device() calls
device_del() which frees all memory allocated by
devm_kzalloc() and linked to
ndev->conn_info_list 2) nci_rx_work() could try
to queue nci_conn_info to ndev->conn_info_list
which could be leaked Thus,
nfc_unregister_device() is split into two
functions so we can remove rfkill interfaces only
before nci_close_device(). [0]:
DEBUG_LOCKS_WARN_ON(1) WARNING:
kernel/locking/lockdep.c:238 at hlock_class
kernel/locking/lockdep.c:238 [inline], CPU#0:
syz.0.8675/6349 WARNING:
kernel/locking/lockdep.c:238 at check_wait_context
kernel/locking/lockdep.c:4854 [inline], CPU#0:
syz.0.8675/6349 WARNING:
kernel/locking/lockdep.c:238 at
__lock_acquire+0x39d/0x2cf0
kernel/locking/lockdep.c:5187, CPU#0:
syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0
PID: 6349 Comm: syz.0.8675 Not tainted syzkaller
#0 PREEMPT(full) Hardware name: Google Google
Compute Engine/Google Compute Engine, BIOS Google
01/13/2026 RIP: 0010:hlock_class
kernel/locking/lockdep.c:238 [inline] RIP:
0010:check_wait_context
kernel/locking/lockdep.c:4854 [inline] RIP:
0010:__lock_acquire+0x3a4/0x2cf0
kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74
24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50
e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b
3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98
c4 00 00 00 41 8b 45 20 25 ff 1f RSP:
0018:ffffc9000c767680 EFLAGS: 00010046 RAX:
0000000000000001 RBX: 0000000000040000 RCX:
0000000000080000 RDX: ffffc90013080000 RSI:
ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP:
0000000000000003 R08: ffffffff8fef35a3 R09:
1ffffffff1fde6b4 R10: dffffc0000000000 R11:
fffffbfff1fde6b5 R12: 00000000000012a2 R13:
ffff888030338ba8 R14: ffff888030338000 R15:
ffff888030338b30 FS: 00007fa5995f66c0(0000)
GS:ffff8881256f8000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4:
00000000003526f0 Call Trace: <TASK>
lock_acquire+0x106/0x330
kernel/locking/lockdep.c:5868
touch_wq_lockdep_map+0xcb/0x180
kernel/workqueue.c:3940
__flush_workqueue+0x14b/0x14f0
kernel/workqueue.c:3982
nci_close_device+0x302/0x630
net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50
net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290
net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100
net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440
net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0
net/rfkill/core.c:1301 vfs_write+0x29a/0xb90
fs/read_write.c:684 ksys_write+0x150/0x270
fs/read_write.c:738 do_syscall_x64
arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:
0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00
00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89
d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05
<48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff
ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028
EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX:
ffffffffffffffda RBX: 00007fa59b615fa0 RCX:
00007fa59b39acb9 RDX: 0000000000000008 RSI:
0000200000000080 RDI: 0000000000000007 RBP:
00007fa59b408bf7 R08: ---truncated--- |
| CVE-2026-23168 |
In the Linux kernel, the
following vulnerability has been resolved:
flex_proportions: make fprop_new_period() hardirq
safe Bernd has reported a lockdep splat from
flexible proportions code that is essentially
complaining about the following race: <timer
fires> run_timer_softirq - we are in softirq
context call_timer_fn writeout_period
fprop_new_period
write_seqcount_begin(&p->sequence);
<hardirq is raised> ... blk_mq_end_request()
blk_update_request() ext4_end_bio()
folio_end_writeback() __wb_writeout_add()
__fprop_add_percpu_max() if (unlikely(max_frac
< FPROP_FRAC_BASE)) { fprop_fraction_percpu()
seq = read_seqcount_begin(&p->sequence); -
sees odd sequence so loops indefinitely Note that
a deadlock like this is only possible if the bdi
has configured maximum fraction of writeout
throughput which is very rare in general but
frequent for example for FUSE bdis. To fix this
problem we have to make sure write section of the
sequence counter is irqsafe. |
| CVE-2026-23170 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/imx/tve: fix probe device leak Make sure to
drop the reference taken to the DDC device during
probe on probe failure (e.g. probe deferral) and
on driver unbind. |
| CVE-2026-23172 |
In the Linux kernel, the
following vulnerability has been resolved: net:
wwan: t7xx: fix potential skb->frags overflow
in RX path When receiving data in the DPMAIF RX
path, the t7xx_dpmaif_set_frag_to_skb() function
adds page fragments to an skb without checking if
the number of fragments has exceeded
MAX_SKB_FRAGS. This could lead to a buffer
overflow in skb_shinfo(skb)->frags[] array,
corrupting adjacent memory and potentially causing
kernel crashes or other undefined behavior. This
issue was identified through static code analysis
by comparing with a similar vulnerability fixed in
the mt76 driver commit b102f0c522cf ("mt76: fix
array overflow on receiving too many fragments for
a packet"). The vulnerability could be triggered
if the modem firmware sends packets with excessive
fragments. While under normal protocol conditions
(MTU 3080 bytes, BAT buffer 3584 bytes), a single
packet should not require additional fragments,
the kernel should not blindly trust firmware
behavior. Malicious, buggy, or compromised
firmware could potentially craft packets with more
fragments than the kernel expects. Fix this by
adding a bounds check before calling
skb_add_rx_frag() to ensure nr_frags does not
exceed MAX_SKB_FRAGS. The check must be performed
before unmapping to avoid a page leak and double
DMA unmap during device teardown. |
| CVE-2026-23173 |
In the Linux kernel, the
following vulnerability has been resolved:
net/mlx5e: TC, delete flows only for existing
peers When deleting TC steering flows, iterate
only over actual devcom peers instead of assuming
all possible ports exist. This avoids touching
non-existent peers and ensures cleanup is limited
to devices the driver is currently connected to.
BUG: kernel NULL pointer dereference, address:
0000000000000008 #PF: supervisor write access in
kernel mode #PF: error_code(0x0002) - not-present
page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP
CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted
6.18.0+ #156 NONE Hardware name: QEMU Standard PC
(Q35 + ICH9, 2009), BIOS
rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org
04/01/2014 RIP:
0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200
[mlx5_core] Code: 00 00 a8 08 74 a8 49 8b 46 18 f6
c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7
96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff
<48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c
24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528
EFLAGS: 00010246 RAX: 0000000000000000 RBX:
dead000000000122 RCX: 0000000000000000 RDX:
ff11000143691580 RSI: ff110001026e5000 RDI:
ff11000106f3d2a0 RBP: dead000000000100 R08:
00000000000003fd R09: 0000000000000002 R10:
ff11000101c75690 R11: ff1100085faea178 R12:
ff11000115f0ae78 R13: 0000000000000000 R14:
ff11000115f0a800 R15: ff11000106f3d2a0 FS:
00007f35236bf740(0000) GS:ff110008dc809000(0000)
knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000
CR0: 0000000080050033 CR2: 0000000000000008 CR3:
0000000157a01001 CR4: 0000000000373eb0 Call Trace:
<TASK> mlx5e_tc_del_flow+0x46/0x270
[mlx5_core] mlx5e_flow_put+0x25/0x50 [mlx5_core]
mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core]
tc_setup_cb_reoffload+0x20/0x80
fl_reoffload+0x26f/0x2f0 [cls_flower] ?
mlx5e_tc_reoffload_flows_work+0xc0/0xc0
[mlx5_core] ?
mlx5e_tc_reoffload_flows_work+0xc0/0xc0
[mlx5_core] tcf_block_playback_offloads+0x9e/0x1c0
tcf_block_unbind+0x7b/0xd0
tcf_block_setup+0x186/0x1d0
tcf_block_offload_cmd.isra.0+0xef/0x130
tcf_block_offload_unbind+0x43/0x70
__tcf_block_put+0x85/0x160
ingress_destroy+0x32/0x110 [sch_ingress]
__qdisc_destroy+0x44/0x100 qdisc_graft+0x22b/0x610
tc_get_qdisc+0x183/0x4d0
rtnetlink_rcv_msg+0x2d7/0x3d0 ?
rtnl_calcit.isra.0+0x100/0x100
netlink_rcv_skb+0x53/0x100
netlink_unicast+0x249/0x320 ?
__alloc_skb+0x102/0x1f0
netlink_sendmsg+0x1e3/0x420
__sock_sendmsg+0x38/0x60
____sys_sendmsg+0x1ef/0x230 ?
copy_msghdr_from_user+0x6c/0xa0
___sys_sendmsg+0x7f/0xc0 ?
___sys_recvmsg+0x8a/0xc0 ?
__sys_sendto+0x119/0x180 __sys_sendmsg+0x61/0xb0
do_syscall_64+0x55/0x640
entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP:
0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64
89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e
fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05
<48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48
89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638
EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX:
ffffffffffffffda RBX: 000055a2efcc75e0 RCX:
00007f35238bb764 RDX: 0000000000000000 RSI:
00007ffed4c356a0 RDI: 0000000000000003 RBP:
00007ffed4c35710 R08: 0000000000000010 R09:
00007f3523984b20 R10: 0000000000000004 R11:
0000000000000202 R12: 00007ffed4c35790 R13:
000000006947df8f R14: 000055a2efcc75e0 R15:
00007ffed4c35780 |
| CVE-2026-23176 |
In the Linux kernel, the
following vulnerability has been resolved:
platform/x86: toshiba_haps: Fix memory leaks in
add/remove routines toshiba_haps_add() leaks the
haps object allocated by it if it returns an error
after allocating that object successfully.
toshiba_haps_remove() does not free the object
pointed to by toshiba_haps before clearing that
pointer, so it becomes unreachable allocated
memory. Address these memory leaks by using
devm_kzalloc() for allocating the memory in
question. |
| CVE-2026-23178 |
In the Linux kernel, the
following vulnerability has been resolved: HID:
i2c-hid: fix potential buffer overflow in
i2c_hid_get_report() `i2c_hid_xfer` is used to
read `recv_len + sizeof(__le16)` bytes of data
into `ihid->rawbuf`. The former can come from
the userspace in the hidraw driver and is only
bounded by HID_MAX_BUFFER_SIZE(16384) by default
(unless we also set `max_buffer_size` field of
`struct hid_ll_driver` which we do not). The
latter has size determined at runtime by the
maximum size of different report types you could
receive on any particular device and can be a much
smaller value. Fix this by truncating `recv_len`
to `ihid->bufsize - sizeof(__le16)`. The impact
is low since access to hidraw devices requires
root. |
| CVE-2026-23179 |
In the Linux kernel, the
following vulnerability has been resolved:
nvmet-tcp: fixup hang in
nvmet_tcp_listen_data_ready() When the socket is
closed while in TCP_LISTEN a callback is run to
flush all outstanding packets, which in turns
calls nvmet_tcp_listen_data_ready() with the
sk_callback_lock held. So we need to check if we
are in TCP_LISTEN before attempting to get the
sk_callback_lock() to avoid a deadlock. |
| CVE-2026-23180 |
In the Linux kernel, the
following vulnerability has been resolved:
dpaa2-switch: add bounds check for if_id in IRQ
handler The IRQ handler extracts if_id from the
upper 16 bits of the hardware status register and
uses it to index into ethsw->ports[] without
validation. Since if_id can be any 16-bit value
(0-65535) but the ports array is only allocated
with sw_attr.num_ifs elements, this can lead to an
out-of-bounds read potentially. Add a bounds check
before accessing the array, consistent with the
existing validation in dpaa2_switch_rx(). |
| CVE-2026-23182 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
tegra: Fix a memory leak in tegra_slink_probe() In
tegra_slink_probe(), when platform_get_irq()
fails, it directly returns from the function with
an error code, which causes a memory leak. Replace
it with a goto label to ensure proper
cleanup. |
| CVE-2026-23187 |
In the Linux kernel, the
following vulnerability has been resolved:
pmdomain: imx8m-blk-ctrl: fix out-of-range access
of bc->domains Fix out-of-range access of
bc->domains in imx8m_blk_ctrl_remove(). |
| CVE-2026-23190 |
In the Linux kernel, the
following vulnerability has been resolved: ASoC:
amd: fix memory leak in acp3x pdm dma ops |
| CVE-2026-23191 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
aloop: Fix racy access at PCM trigger The PCM
trigger callback of aloop driver tries to check
the PCM state and stop the stream of the tied
substream in the corresponding cable. Since both
check and stop operations are performed outside
the cable lock, this may result in UAF when a
program attempts to trigger frequently while
opening/closing the tied stream, as spotted by
fuzzers. For addressing the UAF, this patch
changes two things: - It covers the most of code
in loopback_check_format() with cable->lock
spinlock, and add the proper NULL checks. This
avoids already some racy accesses. - In addition,
now we try to check the state of the capture PCM
stream that may be stopped in this function, which
was the major pain point leading to UAF. |
| CVE-2026-23193 |
In the Linux kernel, the
following vulnerability has been resolved: scsi:
target: iscsi: Fix use-after-free in
iscsit_dec_session_usage_count() In
iscsit_dec_session_usage_count(), the function
calls complete() while holding the
sess->session_usage_lock. Similar to the
connection usage count logic, the waiter signaled
by complete() (e.g., in the session release path)
may wake up and free the iscsit_session structure
immediately. This creates a race condition where
the current thread may attempt to execute
spin_unlock_bh() on a session structure that has
already been deallocated, resulting in a KASAN
slab-use-after-free. To resolve this, release the
session_usage_lock before calling complete() to
ensure all dereferences of the sess pointer are
finished before the waiter is allowed to proceed
with deallocation. |
| CVE-2026-23198 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
Don't clobber irqfd routing type when deassigning
irqfd When deassigning a KVM_IRQFD, don't clobber
the irqfd's copy of the IRQ's routing entry as
doing so breaks kvm_arch_irq_bypass_del_producer()
on x86 and arm64, which explicitly look for
KVM_IRQ_ROUTING_MSI. Instead, to handle a
concurrent routing update, verify that the irqfd
is still active before consuming the routing
information. As evidenced by the x86 and arm64
bugs, and another bug in
kvm_arch_update_irqfd_routing() (see below),
clobbering the entry type without notifying arch
code is surprising and error prone. As a bonus,
checking that the irqfd is active provides a
convenient location for documenting _why_ KVM must
not consume the routing entry for an irqfd that is
in the process of being deassigned: once the irqfd
is deleted from the list (which happens *before*
the eventfd is detached), it will no longer
receive updates via kvm_irq_routing_update(), and
so KVM could deliver an event using stale routing
information (relative to KVM_SET_GSI_ROUTING
returning to userspace). As an even better bonus,
explicitly checking for the irqfd being active
fixes a similar bug to the one the clobbering is
trying to prevent: if an irqfd is deactivated, and
then its routing is changed,
kvm_irq_routing_update() won't invoke
kvm_arch_update_irqfd_routing() (because the irqfd
isn't in the list). And so if the irqfd is in
bypass mode, IRQs will continue to be posted using
the old routing information. As for
kvm_arch_irq_bypass_del_producer(), clobbering the
routing type results in KVM incorrectly keeping
the IRQ in bypass mode, which is especially
problematic on AMD as KVM tracks IRQs that are
being posted to a vCPU in a list whose lifetime is
tied to the irqfd. Without the help of KASAN to
detect use-after-free, the most common sympton on
AMD is a NULL pointer deref in
amd_iommu_update_ga() due to the memory for irqfd
structure being re-allocated and zeroed, resulting
in irqfd->irq_bypass_data being NULL when read
by avic_update_iommu_vcpu_affinity(): BUG: kernel
NULL pointer dereference, address:
0000000000000018 #PF: supervisor read access in
kernel mode #PF: error_code(0x0000) - not-present
page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067
PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID:
40383 Comm: vfio_irq_test Tainted: G U W O
6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted:
[U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name:
Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS
34.78.2-0 09/05/2025 RIP:
0010:amd_iommu_update_ga+0x19/0xe0 Call Trace:
<TASK>
avic_update_iommu_vcpu_affinity+0x3d/0x90
[kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd]
kvm_arch_vcpu_load+0x89/0x210 [kvm]
vcpu_load+0x30/0x40 [kvm]
kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]
kvm_vcpu_ioctl+0x571/0x6a0 [kvm]
__se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0
entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP:
0033:0x46893b </TASK> ---[ end trace
0000000000000000 ]--- If AVIC is inhibited when
the irfd is deassigned, the bug will manifest as
list corruption, e.g. on the next irqfd
assignment. list_add corruption. next->prev
should be prev (ffff8d474d5cd588), but was
0000000000000000. (next=ffff8d8658f86530).
------------[ cut here ]------------ kernel BUG at
lib/list_debug.c:31! Oops: invalid opcode: 0000
[#1] SMP CPU: 128 UID: 0 PID: 80818 Comm:
vfio_irq_test Tainted: G U W O
6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted:
[U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name:
Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS
34.78.2-0 09/05/2025 RIP:
0010:__list_add_valid_or_report+0x97/0xc0 Call
Trace: <TASK>
avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]
kvm_pi_update_irte+0xbf/0x190 [kvm]
kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]
irq_bypass_register_consumer+0xcd/0x170 [irqbypa
---truncated--- |
| CVE-2026-23200 |
In the Linux kernel, the
following vulnerability has been resolved: ipv6:
Fix ECMP sibling count mismatch when clearing
RTF_ADDRCONF syzbot reported a kernel BUG in
fib6_add_rt2node() when adding an IPv6 route. [0]
Commit f72514b3c569 ("ipv6: clear RA flags when
adding a static route") introduced logic to clear
RTF_ADDRCONF from existing routes when a static
route with the same nexthop is added. However,
this causes a problem when the existing route has
a gateway. When RTF_ADDRCONF is cleared from a
route that has a gateway, that route becomes
eligible for ECMP, i.e. rt6_qualify_for_ecmp()
returns true. The issue is that this route was
never added to the fib6_siblings list. This leads
to a mismatch between the following counts: - The
sibling count computed by iterating fib6_next
chain, which includes the newly ECMP-eligible
route - The actual siblings in fib6_siblings list,
which does not include that route When a
subsequent ECMP route is added, fib6_add_rt2node()
hits BUG_ON(sibling->fib6_nsiblings !=
rt->fib6_nsiblings) because the counts don't
match. Fix this by only clearing RTF_ADDRCONF when
the existing route does not have a gateway. Routes
without a gateway cannot qualify for ECMP anyway
(rt6_qualify_for_ecmp() requires
fib_nh_gw_family), so clearing RTF_ADDRCONF on
them is safe and matches the original intent of
the commit. [0]: kernel BUG at
net/ipv6/ip6_fib.c:1217! Oops: invalid opcode:
0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6010
Comm: syz.0.17 Not tainted syzkaller #0
PREEMPT(full) Hardware name: Google Google Compute
Engine/Google Compute Engine, BIOS Google
10/25/2025 RIP:
0010:fib6_add_rt2node+0x3433/0x3470
net/ipv6/ip6_fib.c:1217 [...] Call Trace:
<TASK> fib6_add+0x8da/0x18a0
net/ipv6/ip6_fib.c:1532 __ip6_ins_rt
net/ipv6/route.c:1351 [inline]
ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946
ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571
inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577
sock_do_ioctl+0xdc/0x300 net/socket.c:1245
sock_ioctl+0x576/0x790 net/socket.c:1366 vfs_ioctl
fs/ioctl.c:51 [inline] __do_sys_ioctl
fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170
fs/ioctl.c:583 do_syscall_x64
arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
| CVE-2026-23202 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
tegra210-quad: Protect curr_xfer in
tegra_qspi_combined_seq_xfer The curr_xfer field
is read by the IRQ handler without holding the
lock to check if a transfer is in progress. When
clearing curr_xfer in the combined sequence
transfer loop, protect it with the spinlock to
prevent a race with the interrupt handler. Protect
the curr_xfer clearing at the exit path of
tegra_qspi_combined_seq_xfer() with the spinlock
to prevent a race with the interrupt handler that
reads this field. Without this protection, the IRQ
handler could read a partially updated curr_xfer
value, leading to NULL pointer dereference or
use-after-free. |
| CVE-2026-23204 |
In the Linux kernel, the
following vulnerability has been resolved:
net/sched: cls_u32: use
skb_header_pointer_careful() skb_header_pointer()
does not fully validate negative @offset values.
Use skb_header_pointer_careful() instead. GangMin
Kim provided a report and a repro fooling
u32_classify(): BUG: KASAN: slab-out-of-bounds in
u32_classify+0x1180/0x11b0
net/sched/cls_u32.c:221 |
| CVE-2026-23205 |
In the Linux kernel, the
following vulnerability has been resolved:
smb/client: fix memory leak in smb2_open_file()
Reproducer: 1. server: directories are exported
read-only 2. client: mount -t cifs
//${server_ip}/export /mnt 3. client: dd
if=/dev/zero of=/mnt/file bs=512 count=1000
oflag=direct 4. client: umount /mnt 5. client:
sleep 1 6. client: modprobe -r cifs The error
message is as follows:
=============================================================================
BUG cifs_small_rq (Not tainted): Objects remaining
on __kmem_cache_shutdown()
-----------------------------------------------------------------------------
Object 0x00000000d47521be @offset=14336 ...
WARNING: mm/slub.c:1251 at
__kmem_cache_shutdown+0x34e/0x440, CPU#0:
modprobe/1577 ... Call Trace: <TASK>
kmem_cache_destroy+0x94/0x190
cifs_destroy_request_bufs+0x3e/0x50 [cifs]
cleanup_module+0x4e/0x540 [cifs]
__se_sys_delete_module+0x278/0x400
__x64_sys_delete_module+0x5f/0x70
x64_sys_call+0x2299/0x2ff0
do_syscall_64+0x89/0x350
entry_SYSCALL_64_after_hwframe+0x76/0x7e ...
kmem_cache_destroy cifs_small_rq: Slab cache still
has objects when called from
cifs_destroy_request_bufs+0x3e/0x50 [cifs]
WARNING: mm/slab_common.c:532 at
kmem_cache_destroy+0x16b/0x190, CPU#0:
modprobe/1577 |
| CVE-2026-23206 |
In the Linux kernel, the
following vulnerability has been resolved:
dpaa2-switch: prevent ZERO_SIZE_PTR dereference
when num_ifs is zero The driver allocates arrays
for ports, FDBs, and filter blocks using kcalloc()
with ethsw->sw_attr.num_ifs as the element
count. When the device reports zero interfaces
(either due to hardware configuration or firmware
issues), kcalloc(0, ...) returns ZERO_SIZE_PTR
(0x10) instead of NULL. Later in
dpaa2_switch_probe(), the NAPI initialization
unconditionally accesses
ethsw->ports[0]->netdev, which attempts to
dereference ZERO_SIZE_PTR (address 0x10),
resulting in a kernel panic. Add a check to ensure
num_ifs is greater than zero after retrieving
device attributes. This prevents the zero-sized
allocations and subsequent invalid pointer
dereference. |
| CVE-2026-23212 |
In the Linux kernel, the
following vulnerability has been resolved:
bonding: annotate data-races around
slave->last_rx slave->last_rx and
slave->target_last_arp_rx[...] can be read and
written locklessly. Add READ_ONCE() and
WRITE_ONCE() annotations. syzbot reported: BUG:
KCSAN: data-race in bond_rcv_validate /
bond_rcv_validate write to 0xffff888149f0d428 of 8
bytes by interrupt on cpu 1:
bond_rcv_validate+0x202/0x7a0
drivers/net/bonding/bond_main.c:3335
bond_handle_frame+0xde/0x5e0
drivers/net/bonding/bond_main.c:1533
__netif_receive_skb_core+0x5b1/0x1950
net/core/dev.c:6039 __netif_receive_skb_one_core
net/core/dev.c:6150 [inline]
__netif_receive_skb+0x59/0x270 net/core/dev.c:6265
netif_receive_skb_internal net/core/dev.c:6351
[inline] netif_receive_skb+0x4b/0x2d0
net/core/dev.c:6410 ... write to
0xffff888149f0d428 of 8 bytes by interrupt on cpu
0: bond_rcv_validate+0x202/0x7a0
drivers/net/bonding/bond_main.c:3335
bond_handle_frame+0xde/0x5e0
drivers/net/bonding/bond_main.c:1533
__netif_receive_skb_core+0x5b1/0x1950
net/core/dev.c:6039 __netif_receive_skb_one_core
net/core/dev.c:6150 [inline]
__netif_receive_skb+0x59/0x270 net/core/dev.c:6265
netif_receive_skb_internal net/core/dev.c:6351
[inline] netif_receive_skb+0x4b/0x2d0
net/core/dev.c:6410 br_netif_receive_skb
net/bridge/br_input.c:30 [inline] NF_HOOK
include/linux/netfilter.h:318 [inline] ... value
changed: 0x0000000100005365 ->
0x0000000100005366 |
| CVE-2026-23213 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amd/pm: Disable MMIO access during SMU Mode 1
reset During Mode 1 reset, the ASIC undergoes a
reset cycle and becomes temporarily inaccessible
via PCIe. Any attempt to access MMIO registers
during this window (e.g., from interrupt handlers
or other driver threads) can result in uncompleted
PCIe transactions, leading to NMI panics or system
hangs. To prevent this, set the `no_hw_access`
flag to true immediately after triggering the
reset. This signals other driver components to
skip register accesses while the device is
offline. A memory barrier `smp_mb()` is added to
ensure the flag update is globally visible to all
cores before the driver enters the sleep/wait
state. (cherry picked from commit
7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4) |
| CVE-2026-23214 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
reject new transactions if the fs is fully
read-only [BUG] There is a bug report where a
heavily fuzzed fs is mounted with all rescue mount
options, which leads to the following warnings
during unmount: BTRFS: Transaction aborted (error
-22) Modules linked in: CPU: 0 UID: 0 PID: 9758
Comm: repro.out Not tainted
6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX,
1996), BIOS 1.15.0-1 04/01/2014 RIP:
0010:find_free_extent_update_loop
fs/btrfs/extent-tree.c:4208 [inline] RIP:
0010:find_free_extent+0x52f0/0x5d20
fs/btrfs/extent-tree.c:4611 Call Trace:
<TASK> btrfs_reserve_extent+0x2cd/0x790
fs/btrfs/extent-tree.c:4705
btrfs_alloc_tree_block+0x1e1/0x10e0
fs/btrfs/extent-tree.c:5157
btrfs_force_cow_block+0x578/0x2410
fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80
fs/btrfs/ctree.c:708
btrfs_search_slot+0xcad/0x2b50
fs/btrfs/ctree.c:2130
btrfs_truncate_inode_items+0x45d/0x2350
fs/btrfs/inode-item.c:499
btrfs_evict_inode+0x923/0xe70
fs/btrfs/inode.c:5628 evict+0x5f4/0xae0
fs/inode.c:837 __dentry_kill+0x209/0x660
fs/dcache.c:670 finish_dput+0xc9/0x480
fs/dcache.c:879
shrink_dcache_for_umount+0xa0/0x170
fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0
fs/super.c:621 kill_anon_super+0x3b/0x70
fs/super.c:1289 btrfs_kill_super+0x41/0x50
fs/btrfs/super.c:2127
deactivate_locked_super+0xbc/0x130 fs/super.c:474
cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318
task_work_run+0x1d4/0x260 kernel/task_work.c:233
exit_task_work include/linux/task_work.h:40
[inline] do_exit+0x694/0x22f0 kernel/exit.c:971
do_group_exit+0x21c/0x2d0 kernel/exit.c:1112
__do_sys_exit_group kernel/exit.c:1123 [inline]
__se_sys_exit_group kernel/exit.c:1121 [inline]
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121
x64_sys_call+0x2210/0x2210
arch/x86/include/generated/asm/syscalls_64.h:232
do_syscall_x64 arch/x86/entry/syscall_64.c:63
[inline] do_syscall_64+0xe8/0xf80
arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:
0033:0x44f639 Code: Unable to access opcode bytes
at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS:
00000246 ORIG_RAX: 00000000000000e7 RAX:
ffffffffffffffda RBX: 00000000004c32f0 RCX:
000000000044f639 RDX: 000000000000003c RSI:
00000000000000e7 RDI: 0000000000000001 RBP:
0000000000000001 R08: ffffffffffffffc0 R09:
0000000000000000 R10: 0000000000000000 R11:
0000000000000246 R12: 00000000004c32f0 R13:
0000000000000001 R14: 0000000000000000 R15:
0000000000000001 </TASK> Since rescue mount
options will mark the full fs read-only, there
should be no new transaction triggered. But during
unmount we will evict all inodes, which can
trigger a new transaction, and triggers warnings
on a heavily corrupted fs. [CAUSE] Btrfs allows
new transaction even on a read-only fs, this is to
allow log replay happen even on read-only mounts,
just like what ext4/xfs do. However with rescue
mount options, the fs is fully read-only and
cannot be remounted read-write, thus in that case
we should also reject any new transactions. [FIX]
If we find the fs has rescue mount options, we
should treat the fs as error, so that no new
transaction can be started. |
| CVE-2026-23215 |
In the Linux kernel, the
following vulnerability has been resolved:
x86/vmware: Fix hypercall clobbers Fedora QA
reported the following panic: BUG: unable to
handle page fault for address: 0000000040003e54
#PF: supervisor write access in kernel mode #PF:
error_code(0x0002) - not-present page Hardware
name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
edk2-20251119-3.fc43 11/19/2025 RIP:
0010:vmware_hypercall4.constprop.0+0x52/0x90 ..
Call Trace: vmmouse_report_events+0x13e/0x1b0
psmouse_handle_byte+0x15/0x60
ps2_interrupt+0x8a/0xd0 ... because the QEMU
VMware mouse emulation is buggy, and clears the
top 32 bits of %rdi that the kernel kept a pointer
in. The QEMU vmmouse driver saves and restores the
register state in a "uint32_t data[6];" and as a
result restores the state with the high bits all
cleared. RDI originally contained the value of a
valid kernel stack address (0xff5eeb3240003e54).
After the vmware hypercall it now contains
0x40003e54, and we get a page fault as a result
when it is dereferenced. The proper fix would be
in QEMU, but this works around the issue in the
kernel to keep old setups working, when old
kernels had not happened to keep any state in %rdi
over the hypercall. In theory this same issue
exists for all the hypercalls in the vmmouse
driver; in practice it has only been seen with
vmware_hypercall3() and vmware_hypercall4(). For
now, just mark RDI/RSI as clobbered for those two
calls. This should have a minimal effect on code
generation overall as it should be rare for the
compiler to want to make RDI/RSI live across
hypercalls. |
| CVE-2026-23216 |
In the Linux kernel, the
following vulnerability has been resolved: scsi:
target: iscsi: Fix use-after-free in
iscsit_dec_conn_usage_count() In
iscsit_dec_conn_usage_count(), the function calls
complete() while holding the
conn->conn_usage_lock. As soon as complete() is
invoked, the waiter (such as
iscsit_close_connection()) may wake up and proceed
to free the iscsit_conn structure. If the waiter
frees the memory before the current thread reaches
spin_unlock_bh(), it results in a KASAN
slab-use-after-free as the function attempts to
release a lock within the already-freed connection
structure. Fix this by releasing the spinlock
before calling complete(). |
| CVE-2026-23231 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nf_tables: fix use-after-free in
nf_tables_addchain() nf_tables_addchain()
publishes the chain to table->chains via
list_add_tail_rcu() (in nft_chain_add()) before
registering hooks. If nf_tables_register_hook()
then fails, the error path calls nft_chain_del()
(list_del_rcu()) followed by
nf_tables_chain_destroy() with no RCU grace period
in between. This creates two use-after-free
conditions: 1) Control-plane:
nf_tables_dump_chains() traverses table->chains
under rcu_read_lock(). A concurrent dump can still
be walking the chain when the error path frees it.
2) Packet path: for NFPROTO_INET,
nf_register_net_hook() briefly installs the IPv4
hook before IPv6 registration fails. Packets
entering nft_do_chain() via the transient IPv4
hook can still be dereferencing
chain->blob_gen_X when the error path frees the
chain. Add synchronize_rcu() between
nft_chain_del() and the chain destroy so that all
RCU readers -- both dump threads and in-flight
packet evaluation -- have finished before the
chain is freed. |
| CVE-2026-23254 |
In the Linux kernel, the
following vulnerability has been resolved: net:
gro: fix outer network offset The udp GRO complete
stage assumes that all the packets inserted the RX
have the `encapsulation` flag zeroed. Such
assumption is not true, as a few H/W NICs can set
such flag when H/W offloading the checksum for an
UDP encapsulated traffic, the tun driver can
inject GSO packets with UDP encapsulation and the
problematic layout can also be created via a veth
based setup. Due to the above, in the problematic
scenarios, udp4_gro_complete() uses the wrong
network offset (inner instead of outer) to compute
the outer UDP header pseudo checksum, leading to
csum validation errors later on in packet
processing. Address the issue always clearing the
encapsulation flag at GRO completion time. Such
flag will be set again as needed for encapsulated
packets by udp_gro_complete(). |
| CVE-2026-23256 |
In the Linux kernel, the
following vulnerability has been resolved: net:
liquidio: Fix off-by-one error in VF
setup_nic_devices() cleanup In
setup_nic_devices(), the initialization loop jumps
to the label setup_nic_dev_free on failure. The
current cleanup loop while(i--) skip the failing
index i, causing a memory leak. Fix this by
changing the loop to iterate from the current
index i down to 0. Compile tested only. Issue
found using code review. |
| CVE-2026-23257 |
In the Linux kernel, the
following vulnerability has been resolved: net:
liquidio: Fix off-by-one error in PF
setup_nic_devices() cleanup In
setup_nic_devices(), the initialization loop jumps
to the label setup_nic_dev_free on failure. The
current cleanup loop while(i--) skip the failing
index i, causing a memory leak. Fix this by
changing the loop to iterate from the current
index i down to 0. Also, decrement i in the
devlink_alloc failure path to point to the last
successfully allocated index. Compile tested only.
Issue found using code review. |
| CVE-2026-23258 |
In the Linux kernel, the
following vulnerability has been resolved: net:
liquidio: Initialize netdev pointer before queue
setup In setup_nic_devices(), the netdev is
allocated using alloc_etherdev_mq(). However, the
pointer to this structure is stored in
oct->props[i].netdev only after the calls to
netif_set_real_num_rx_queues() and
netif_set_real_num_tx_queues(). If either of these
functions fails, setup_nic_devices() returns an
error without freeing the allocated netdev. Since
oct->props[i].netdev is still NULL at this
point, the cleanup function
liquidio_destroy_nic_device() will fail to find
and free the netdev, resulting in a memory leak.
Fix this by initializing oct->props[i].netdev
before calling the queue setup functions. This
ensures that the netdev is properly accessible for
cleanup in case of errors. Compile tested only.
Issue found using a prototype static analysis tool
and code review. |
| CVE-2026-23260 |
In the Linux kernel, the
following vulnerability has been resolved: regmap:
maple: free entry on mas_store_gfp() failure
regcache_maple_write() allocates a new block
('entry') to merge adjacent ranges and then stores
it with mas_store_gfp(). When mas_store_gfp()
fails, the new 'entry' remains allocated and is
never freed, leaking memory. Free 'entry' on the
failure path; on success continue freeing the
replaced neighbor blocks ('lower',
'upper'). |
| CVE-2026-23261 |
In the Linux kernel, the
following vulnerability has been resolved:
nvme-fc: release admin tagset if init fails
nvme_fabrics creates an NVMe/FC controller in
following path: nvmf_dev_write() ->
nvmf_create_ctrl() -> nvme_fc_create_ctrl()
-> nvme_fc_init_ctrl() nvme_fc_init_ctrl()
allocates the admin blk-mq resources right after
nvme_add_ctrl() succeeds. If any of the subsequent
steps fail (changing the controller state,
scheduling connect work, etc.), we jump to the
fail_ctrl path, which tears down the controller
references but never frees the admin queue/tag
set. The leaked blk-mq allocations match the
kmemleak report seen during blktests nvme/fc.
Check ctrl->ctrl.admin_tagset in the fail_ctrl
path and call nvme_remove_admin_tag_set() when it
is set so that all admin queue allocations are
reclaimed whenever controller setup
aborts. |
| CVE-2026-23262 |
In the Linux kernel, the
following vulnerability has been resolved: gve:
Fix stats report corruption on queue count change
The driver and the NIC share a region in memory
for stats reporting. The NIC calculates its offset
into this region based on the total size of the
stats region and the size of the NIC's stats. When
the number of queues is changed, the driver's
stats region is resized. If the queue count is
increased, the NIC can write past the end of the
allocated stats region, causing memory corruption.
If the queue count is decreased, there is a gap
between the driver and NIC stats, leading to
incorrect stats reporting. This change fixes the
issue by allocating stats region with maximum
size, and the offset calculation for NIC stats is
changed to match with the calculation of the
NIC. |
| CVE-2026-23264 |
In the Linux kernel, the
following vulnerability has been resolved: Revert
"drm/amd: Check if ASPM is enabled from PCIe
subsystem" This reverts commit
7294863a6f01248d72b61d38478978d638641bee. This
commit was erroneously applied again after commit
0ab5d711ec74 ("drm/amd: Refactor `amdgpu_aspm` to
be evaluated per device") removed it, leading to
very hard to debug crashes, when used with a
system with two AMD GPUs of which only one
supports ASPM. (cherry picked from commit
97a9689300eb2b393ba5efc17c8e5db835917080) |
| CVE-2026-23273 |
In the Linux kernel, the
following vulnerability has been resolved:
macvlan: observe an RCU grace period in
macvlan_common_newlink() error path valis reported
that a race condition still happens after my prior
patch. macvlan_common_newlink() might have made
@dev visible before detecting an error, and its
caller will directly call free_netdev(dev). We
must respect an RCU period, either in macvlan or
the core networking stack. After adding a
temporary mdelay(1000) in
macvlan_forward_source_one() to open the race
window, valis repro was: ip link add p1 type veth
peer p2 ip link set address 00:00:00:00:00:20 dev
p1 ip link set up dev p1 ip link set up dev p2 ip
link add mv0 link p2 type macvlan mode source (ip
link add invalid% link p2 type macvlan mode source
macaddr add 00:00:00:00:00:20 &) ; sleep 0.5 ;
ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56
data bytes RTNETLINK answers: Invalid argument
BUG: KASAN: slab-use-after-free in
macvlan_forward_source (drivers/net/macvlan.c:408
drivers/net/macvlan.c:444) Read of size 8 at addr
ffff888016bb89c0 by task e/175 CPU: 1 UID: 1000
PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE
Hardware name: QEMU Standard PC (i440FX + PIIX,
1996), BIOS 1.14.0-2 04/01/2014 Call Trace:
<IRQ> dump_stack_lvl (lib/dump_stack.c:123)
print_report (mm/kasan/report.c:379
mm/kasan/report.c:482) ? macvlan_forward_source
(drivers/net/macvlan.c:408
drivers/net/macvlan.c:444) kasan_report
(mm/kasan/report.c:597) ? macvlan_forward_source
(drivers/net/macvlan.c:408
drivers/net/macvlan.c:444) macvlan_forward_source
(drivers/net/macvlan.c:408
drivers/net/macvlan.c:444) ? tasklet_init
(kernel/softirq.c:983) macvlan_handle_frame
(drivers/net/macvlan.c:501) Allocated by task 169:
kasan_save_stack (mm/kasan/common.c:58)
kasan_save_track
(./arch/x86/include/asm/current.h:25
mm/kasan/common.c:70 mm/kasan/common.c:79)
__kasan_kmalloc (mm/kasan/common.c:419)
__kvmalloc_node_noprof
(./include/linux/kasan.h:263 mm/slub.c:5657
mm/slub.c:7140) alloc_netdev_mqs
(net/core/dev.c:12012) rtnl_create_link
(net/core/rtnetlink.c:3648) rtnl_newlink
(net/core/rtnetlink.c:3830
net/core/rtnetlink.c:3957
net/core/rtnetlink.c:4072) rtnetlink_rcv_msg
(net/core/rtnetlink.c:6958) netlink_rcv_skb
(net/netlink/af_netlink.c:2550) netlink_unicast
(net/netlink/af_netlink.c:1319
net/netlink/af_netlink.c:1344) netlink_sendmsg
(net/netlink/af_netlink.c:1894) __sys_sendto
(net/socket.c:727 net/socket.c:742
net/socket.c:2206) __x64_sys_sendto
(net/socket.c:2209) do_syscall_64
(arch/x86/entry/syscall_64.c:63
arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe
(arch/x86/entry/entry_64.S:131) Freed by task 169:
kasan_save_stack (mm/kasan/common.c:58)
kasan_save_track
(./arch/x86/include/asm/current.h:25
mm/kasan/common.c:70 mm/kasan/common.c:79)
kasan_save_free_info (mm/kasan/generic.c:587)
__kasan_slab_free (mm/kasan/common.c:287) kfree
(mm/slub.c:6674 mm/slub.c:6882) rtnl_newlink
(net/core/rtnetlink.c:3845
net/core/rtnetlink.c:3957
net/core/rtnetlink.c:4072) rtnetlink_rcv_msg
(net/core/rtnetlink.c:6958) netlink_rcv_skb
(net/netlink/af_netlink.c:2550) netlink_unicast
(net/netlink/af_netlink.c:1319
net/netlink/af_netlink.c:1344) netlink_sendmsg
(net/netlink/af_netlink.c:1894) __sys_sendto
(net/socket.c:727 net/socket.c:742
net/socket.c:2206) __x64_sys_sendto
(net/socket.c:2209) do_syscall_64
(arch/x86/entry/syscall_64.c:63
arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe
(arch/x86/entry/entry_64.S:131) |
| CVE-2026-23274 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: xt_IDLETIMER: reject rev0 reuse of
ALARM timer labels IDLETIMER revision 0 rules
reuse existing timers by label and always call
mod_timer() on timer->timer. If the label was
created first by revision 1 with
XT_IDLETIMER_ALARM, the object uses alarm timer
semantics and timer->timer is never
initialized. Reusing that object from revision 0
causes mod_timer() on an uninitialized timer_list,
triggering debugobjects warnings and possible
panic when panic_on_warn=1. Fix this by rejecting
revision 0 rule insertion when an existing timer
with the same label is of ALARM type. |
| CVE-2026-23351 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nft_set_pipapo: split gc into unlink
and reclaim phase Yiming Qian reports
Use-after-free in the pipapo set type: Under a
large number of expired elements, commit-time GC
can run for a very long time in a non-preemptible
context, triggering soft lockup warnings and RCU
stall reports (local denial of service). We must
split GC in an unlink and a reclaim phase. We
cannot queue elements for freeing until pointers
have been swapped. Expired elements are still
exposed to both the packet path and userspace
dumpers via the live copy of the data structure.
call_rcu() does not protect us: dump operations or
element lookups starting after call_rcu has fired
can still observe the free'd element, unless the
commit phase has made enough progress to swap the
clone and live pointers before any new reader has
picked up the old version. This a similar approach
as done recently for the rbtree backend in commit
35f83a75529a ("netfilter: nft_set_rbtree: don't gc
elements on insert"). |
| CVE-2026-23394 |
In the Linux kernel, the
following vulnerability has been resolved:
af_unix: Give up GC if MSG_PEEK intervened. Igor
Ushakov reported that GC purged the receive queue
of an alive socket due to a race with MSG_PEEK
with a nice repro. This is the exact same issue
previously fixed by commit cbcf01128d0a ("af_unix:
fix garbage collect vs MSG_PEEK"). After GC was
replaced with the current algorithm, the cited
commit removed the locking dance in
unix_peek_fds() and reintroduced the same issue.
The problem is that MSG_PEEK bumps a file refcount
without interacting with GC. Consider an SCC
containing sk-A and sk-B, where sk-A is close()d
but can be recv()ed via sk-B. The bad thing
happens if sk-A is recv()ed with MSG_PEEK from
sk-B and sk-B is close()d while GC is checking
unix_vertex_dead() for sk-A and sk-B. GC thread
User thread --------- -----------
unix_vertex_dead(sk-A) -> true <------. \
`------ recv(sk-B, MSG_PEEK) invalidate !! ->
sk-A's file refcount : 1 -> 2 close(sk-B) ->
sk-B's file refcount : 2 -> 1
unix_vertex_dead(sk-B) -> true Initially,
sk-A's file refcount is 1 by the inflight fd in
sk-B recvq. GC thinks sk-A is dead because the
file refcount is the same as the number of its
inflight fds. However, sk-A's file refcount is
bumped silently by MSG_PEEK, which invalidates the
previous evaluation. At this moment, sk-B's file
refcount is 2; one by the open fd, and one by the
inflight fd in sk-A. The subsequent close()
releases one refcount by the former. Finally, GC
incorrectly concludes that both sk-A and sk-B are
dead. One option is to restore the locking dance
in unix_peek_fds(), but we can resolve this more
elegantly thanks to the new algorithm. The point
is that the issue does not occur without the
subsequent close() and we actually do not need to
synchronise MSG_PEEK with the dead SCC detection.
When the issue occurs, close() and GC touch the
same file refcount. If GC sees the refcount being
decremented by close(), it can just give up
garbage-collecting the SCC. Therefore, we only
need to signal the race during MSG_PEEK with a
proper memory barrier to make it visible to the
GC. Let's use seqcount_t to notify GC when
MSG_PEEK occurs and let it defer the SCC to the
next run. This way no locking is needed on the
MSG_PEEK side, and we can avoid imposing a penalty
on every MSG_PEEK unnecessarily. Note that we can
retry within unix_scc_dead() if MSG_PEEK is
detected, but we do not do so to avoid hung task
splat from abusive MSG_PEEK calls. |
| CVE-2026-24688 |
pypdf is a free and
open-source pure-python PDF library. An attacker
who uses an infinite loop vulnerability that is
present in versions prior to 6.6.2 can craft a PDF
which leads to an infinite loop. This requires
accessing the outlines/bookmarks. This has been
fixed in pypdf 6.6.2. If projects cannot upgrade
yet, consider applying the changes from PR #3610
manually. |
| CVE-2026-26157 |
A flaw was found in BusyBox.
Incomplete path sanitization in its archive
extraction utilities allows an attacker to craft
malicious archives that when extracted, and under
specific conditions, may write to files outside
the intended directory. This can lead to arbitrary
file overwrite, potentially enabling code
execution through the modification of sensitive
system files. |
| CVE-2026-26158 |
A flaw was found in BusyBox.
This vulnerability allows an attacker to modify
files outside of the intended extraction directory
by crafting a malicious tar archive containing
unvalidated hardlink or symlink entries. If the
tar archive is extracted with elevated privileges,
this flaw can lead to privilege escalation,
enabling an attacker to gain unauthorized access
to critical system files. |
| CVE-2026-27024 |
pypdf is a free and
open-source pure-python PDF library. Prior to
6.7.1, an attacker who uses this vulnerability can
craft a PDF which leads to an infinite loop. This
requires accessing the children of a TreeObject,
for example as part of outlines. This
vulnerability is fixed in 6.7.1. |
| CVE-2026-27025 |
pypdf is a free and
open-source pure-python PDF library. Prior to
6.7.1, an attacker who uses this vulnerability can
craft a PDF which leads to long runtimes and large
memory consumption. This requires parsing the
/ToUnicode entry of a font with unusually large
values, for example during text extraction. This
vulnerability is fixed in 6.7.1. |
| CVE-2026-27026 |
pypdf is a free and
open-source pure-python PDF library. Prior to
6.7.1, an attacker who uses this vulnerability can
craft a PDF which leads to long runtimes. This
requires a malformed /FlateDecode stream, where
the byte-by-byte decompression is used. This
vulnerability is fixed in 6.7.1. |
| CVE-2026-27199 |
Werkzeug is a comprehensive
WSGI web application library. Versions 3.1.5 and
below, the safe_join function allows Windows
device names as filenames if preceded by other
path segments. This was previously reported as
GHSA-hgf8-39gv-g3f2, but the added filtering
failed to account for the fact that safe_join
accepts paths with multiple segments, such as
example/NUL. The function send_from_directory uses
safe_join to safely serve files at user-specified
paths under a directory. If the application is
running on Windows, and the requested path ends
with a special device name, the file will be
opened successfully, but reading will hang
indefinitely. This issue has been fixed in version
3.1.6. |
| CVE-2026-27205 |
Flask is a web server gateway
interface (WSGI) web application framework. In
versions 3.1.2 and below, when the session object
is accessed, Flask should set the Vary: Cookie
header., resulting in a Use of Cache Containing
Sensitive Information vulnerability. The logic
instructs caches not to cache the response, as it
may contain information specific to a logged in
user. This is handled in most cases, but some
forms of access such as the Python in operator
were overlooked. The severity and risk depend on
the application being hosted behind a caching
proxy that doesn't ignore responses with cookies,
not setting a Cache-Control header to mark pages
as private or non-cacheable, and accessing the
session in a way that only touches keys without
reading values or mutating the session. The issue
has been fixed in version 3.1.3. |
| CVE-2026-27628 |
pypdf is a free and
open-source pure-python PDF library. Prior to
6.7.2, an attacker who uses this vulnerability can
craft a PDF which leads to an infinite loop. This
requires reading the file. This has been fixed in
pypdf 6.7.2. As a workaround, one may apply the
patch manually. |
| CVE-2026-27888 |
pypdf is a free and
open-source pure-python PDF library. Prior to
6.7.3, an attacker who uses this vulnerability can
craft a PDF which leads to the RAM being
exhausted. This requires accessing the `xfa`
property of a reader or writer and the
corresponding stream being compressed using
`/FlateDecode`. This has been fixed in pypdf
6.7.3. As a workaround, apply the patch
manually. |
| CVE-2026-28351 |
pypdf is a free and
open-source pure-python PDF library. Prior to
version 6.7.4, an attacker who uses this
vulnerability can craft a PDF which leads to large
memory usage. This requires parsing the content
stream using the RunLengthDecode filter. This has
been fixed in pypdf 6.7.4. As a workaround,
consider applying the changes from PR
#3664. |
| CVE-2026-28804 |
pypdf is a free and
open-source pure-python PDF library. Prior to
version 6.7.5, an attacker who uses this
vulnerability can craft a PDF which leads to long
runtimes. This requires accessing a stream which
uses the /ASCIIHexDecode filter. This issue has
been patched in version 6.7.5. |
| CVE-2026-30997 |
An out-of-bounds read in the
read_global_param() function (libavcodec/av1dec.c)
of FFmpeg v8.0.1 allows attackers to cause a
Denial of Service (DoS) via a crafted
input. |
| CVE-2026-30998 |
An improper resource
deallocation and closure vulnerability in the
tools/zmqsend.c component of FFmpeg v8.0.1 allows
attackers to cause a Denial of Service (DoS) via
supplying a crafted input file. |
| CVE-2026-30999 |
A heap buffer overflow in the
av_bprint_finalize() function of FFmpeg v8.0.1
allows attackers to cause a Denial of Service
(DoS) via a crafted input. |
| CVE-2026-31419 |
In the Linux kernel, the
following vulnerability has been resolved: net:
bonding: fix use-after-free in
bond_xmit_broadcast() bond_xmit_broadcast() reuses
the original skb for the last slave (determined by
bond_is_last_slave()) and clones it for others.
Concurrent slave enslave/release can mutate the
slave list during RCU-protected iteration,
changing which slave is "last" mid-loop. This
causes the original skb to be double-consumed
(double-freed). Replace the racy
bond_is_last_slave() check with a simple index
comparison (i + 1 == slaves_count) against the
pre-snapshot slave count taken via READ_ONCE()
before the loop. This preserves the zero-copy
optimization for the last slave while making the
"last" determination stable against concurrent
list mutations. The UAF can trigger the following
crash:
==================================================================
BUG: KASAN: slab-use-after-free in skb_clone Read
of size 8 at addr ffff888100ef8d40 by task
exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit
Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace:
<TASK> dump_stack_lvl (lib/dump_stack.c:123)
print_report (mm/kasan/report.c:379
mm/kasan/report.c:482) kasan_report
(mm/kasan/report.c:597) skb_clone
(include/linux/skbuff.h:1724
include/linux/skbuff.h:1792
include/linux/skbuff.h:3396
net/core/skbuff.c:2108) bond_xmit_broadcast
(drivers/net/bonding/bond_main.c:5334)
bond_start_xmit
(drivers/net/bonding/bond_main.c:5567
drivers/net/bonding/bond_main.c:5593)
dev_hard_start_xmit
(include/linux/netdevice.h:5325
include/linux/netdevice.h:5334 net/core/dev.c:3871
net/core/dev.c:3887) __dev_queue_xmit
(include/linux/netdevice.h:3601
net/core/dev.c:4838) ip6_finish_output2
(include/net/neighbour.h:540
include/net/neighbour.h:554
net/ipv6/ip6_output.c:136) ip6_finish_output
(net/ipv6/ip6_output.c:208
net/ipv6/ip6_output.c:219) ip6_output
(net/ipv6/ip6_output.c:250) ip6_send_skb
(net/ipv6/ip6_output.c:1985) udp_v6_send_skb
(net/ipv6/udp.c:1442) udpv6_sendmsg
(net/ipv6/udp.c:1733) __sys_sendto
(net/socket.c:730 net/socket.c:742
net/socket.c:2206) __x64_sys_sendto
(net/socket.c:2209) do_syscall_64
(arch/x86/entry/syscall_64.c:63
arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe
(arch/x86/entry/entry_64.S:130) </TASK>
Allocated by task 147: Freed by task 147: The
buggy address belongs to the object at
ffff888100ef8c80 which belongs to the cache
skbuff_head_cache of size 224 The buggy address is
located 192 bytes inside of freed 224-byte region
[ffff888100ef8c80, ffff888100ef8d60) Memory state
around the buggy address: ffff888100ef8c00: fb fb
fb fb fc fc fc fc fc fc fc fc fc fc fc fc
ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb
fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb
fb fb fb fb fb fb fb fb fc fc fc fc ^
ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb
fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb
fb fb fb fb fb fb fb fb fb fb
================================================================== |
| CVE-2026-31431
(KEV) |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
algif_aead - Revert to operating out-of-place This
mostly reverts commit 72548b093ee3 except for the
copying of the associated data. There is no
benefit in operating in-place in algif_aead since
the source and destination come from different
mappings. Get rid of all the complexity added for
in-place operation and just copy the AD
directly. |
| CVE-2026-31504 |
In the Linux kernel, the
following vulnerability has been resolved: net:
fix fanout UAF in packet_release() via NETDEV_UP
race `packet_release()` has a race window where
`NETDEV_UP` can re-register a socket into a fanout
group's `arr[]` array. The re-registration is not
cleaned up by `fanout_release()`, leaving a
dangling pointer in the fanout array.
`packet_release()` does NOT zero `po->num` in
its `bind_lock` section. After releasing
`bind_lock`, `po->num` is still non-zero and
`po->ifindex` still matches the bound device. A
concurrent `packet_notifier(NETDEV_UP)` that
already found the socket in `sklist` can
re-register the hook. For fanout sockets, this
re-registration calls `__fanout_link(sk, po)`
which adds the socket back into `f->arr[]` and
increments `f->num_members`, but does NOT
increment `f->sk_ref`. The fix sets
`po->num` to zero in `packet_release` while
`bind_lock` is held to prevent NETDEV_UP from
linking, preventing the race window. This bug was
found following an additional audit with Claude
Code based on CVE-2025-38617. |
| CVE-2026-31533 |
In the Linux kernel, the
following vulnerability has been resolved:
net/tls: fix use-after-free in -EBUSY error path
of tls_do_encryption The -EBUSY handling in
tls_do_encryption(), introduced by commit
859054147318 ("net: tls: handle backlogging of
crypto requests"), has a use-after-free due to
double cleanup of encrypt_pending and the
scatterlist entry. When crypto_aead_encrypt()
returns -EBUSY, the request is enqueued to the
cryptd backlog and the async callback
tls_encrypt_done() will be invoked upon
completion. That callback unconditionally restores
the scatterlist entry (sge->offset,
sge->length) and decrements
ctx->encrypt_pending. However, if
tls_encrypt_async_wait() returns an error, the
synchronous error path in tls_do_encryption()
performs the same cleanup again,
double-decrementing encrypt_pending and
double-restoring the scatterlist. The
double-decrement corrupts the encrypt_pending
sentinel (initialized to 1), making
tls_encrypt_async_wait() permanently skip the wait
for pending async callbacks. A subsequent sendmsg
can then free the tls_rec via
bpf_exec_tx_verdict() while a cryptd callback is
still pending, resulting in a use-after-free when
the callback fires on the freed record. Fix this
by skipping the synchronous cleanup when the
-EBUSY async wait returns an error, since the
callback has already handled encrypt_pending and
sge restoration. |
| CVE-2026-31676 |
In the Linux kernel, the
following vulnerability has been resolved: rxrpc:
only handle RESPONSE during service challenge Only
process RESPONSE packets while the service
connection is still in
RXRPC_CONN_SERVICE_CHALLENGING. Check that state
under state_lock before running response
verification and security initialization, then use
a local secured flag to decide whether to queue
the secured-connection work after the state
transition. This keeps duplicate or late RESPONSE
packets from re-running the setup path and removes
the unlocked post-transition state test. |
| CVE-2026-31715 |
In the Linux kernel, the
following vulnerability has been resolved: f2fs:
fix UAF caused by decrementing sbi->nr_pages[]
in f2fs_write_end_io() The xfstests case
"generic/107" and syzbot have both reported a NULL
pointer dereference. The concurrent scenario that
triggers the panic is as follows: F2FS_WB_CP_DATA
write callback umount - f2fs_write_checkpoint -
f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) -
blk_mq_end_request - bio_endio - f2fs_write_end_io
: dec_page_count(sbi, F2FS_WB_CP_DATA) :
wake_up(&sbi->cp_wait) - kill_f2fs_super -
kill_block_super - f2fs_put_super :
iput(sbi->node_inode) : sbi->node_inode =
NULL : f2fs_in_warm_node_list - is_node_folio //
sbi->node_inode is NULL and panic The root
cause is that f2fs_put_super() calls
iput(sbi->node_inode) and sets
sbi->node_inode to NULL after
sbi->nr_pages[F2FS_WB_CP_DATA] is decremented
to zero. As a result, f2fs_in_warm_node_list() may
dereference a NULL node_inode when checking
whether a folio belongs to the node inode, leading
to a panic. This patch fixes the issue by calling
f2fs_in_warm_node_list() before decrementing
sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing
the use-after-free condition. |
| CVE-2026-31826 |
pypdf is a free and
open-source pure-python PDF library. Prior to
6.8.0, an attacker who uses this vulnerability can
craft a PDF which leads to large memory usage.
This requires parsing a content stream with a
rather large /Length value, regardless of the
actual data length inside the stream. This
vulnerability is fixed in 6.8.0. |
| CVE-2026-33123 |
pypdf is a free and
open-source pure-python PDF library. Versions
prior to 6.9.1 allow an attacker to craft a
malicious PDF which leads to long runtimes and/or
large memory usage. Exploitation requires
accessing an array-based stream with many entries.
This issue has been fixed in version
6.9.1. |
| CVE-2026-33230 |
NLTK (Natural Language
Toolkit) is a suite of open source Python modules,
data sets, and tutorials supporting research and
development in Natural Language Processing. In
versions 3.9.3 and prior, `nltk.app.wordnet_app`
contains a reflected cross-site scripting issue in
the `lookup_...` route. A crafted
`lookup_<payload>` URL can inject arbitrary
HTML/JavaScript into the response page because
attacker-controlled `word` data is reflected into
HTML without escaping. This impacts users running
the local WordNet Browser server and can lead to
script execution in the browser origin of that
application. Commit
1c3f799607eeb088cab2491dcf806ae83c29ad8f fixes the
issue. |
| CVE-2026-33231 |
NLTK (Natural Language
Toolkit) is a suite of open source Python modules,
data sets, and tutorials supporting research and
development in Natural Language Processing. In
versions 3.9.3 and prior, `nltk.app.wordnet_app`
allows unauthenticated remote shutdown of the
local WordNet Browser HTTP server when it is
started in its default mode. A simple `GET
/SHUTDOWN%20THE%20SERVER` request causes the
process to terminate immediately via
`os._exit(0)`, resulting in a denial of service.
Commit bbaae83db86a0f49e00f5b0db44a7254c268de9b
patches the issue. |
| CVE-2026-33699 |
pypdf is a free and
open-source pure-python PDF library. Versions
prior to 6.9.2 have a vulnerability in which an
attacker can craft a PDF which leads to an
infinite loop. This requires reading a file in
non-strict mode. This has been fixed in pypdf
6.9.2. If users cannot upgrade yet, consider
applying the changes from the patch
manually. |
| CVE-2026-33865 |
MLflow is vulnerable to Stored
Cross-Site Scripting (XSS) caused by unsafe
parsing of YAML-based MLmodel artifacts in its web
interface. An authenticated attacker can upload a
malicious MLmodel file containing a payload that
executes when another user views the artifact in
the UI. This allows actions such as session
hijacking or performing operations on behalf of
the victim. This issue affects MLflow version
through 3.10.1 |
| CVE-2026-33866 |
MLflow is vulnerable to an
authorization bypass affecting the AJAX endpoint
used to download saved model artifacts. Due to
missing access‑control validation, a user without
permissions to a given experiment can directly
query this endpoint and retrieve model artifacts
they are not authorized to access. This issue
affects MLflow version through 3.10.1 |
| CVE-2026-34267 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Optimizer). Supported versions that are affected
are 8.0.0-8.0.45. Easily exploitable vulnerability
allows high privileged attacker with network
access via multiple protocols to compromise MySQL
Server. Successful attacks of this vulnerability
can result in unauthorized ability to cause a hang
or frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 4.9
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-34270 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Group Replication Plugin). Supported versions that
are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and
9.0.0-9.6.0. Easily exploitable vulnerability
allows low privileged attacker with network access
via multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 6.5
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-34271 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Group Replication Plugin). Supported versions that
are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and
9.0.0-9.6.0. Easily exploitable vulnerability
allows low privileged attacker with network access
via multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 6.5
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-34276 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Group Replication Plugin). Supported versions that
are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and
9.0.0-9.6.0. Easily exploitable vulnerability
allows low privileged attacker with network access
via multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 6.5
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-34278 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Optimizer). Supported versions that are affected
are 8.0.0-8.0.45. Easily exploitable vulnerability
allows high privileged attacker with network
access via multiple protocols to compromise MySQL
Server. Successful attacks of this vulnerability
can result in unauthorized ability to cause a hang
or frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 4.9
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-34293 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
DML). Supported versions that are affected are
8.0.0-8.0.45. Easily exploitable vulnerability
allows high privileged attacker with network
access via multiple protocols to compromise MySQL
Server. Successful attacks of this vulnerability
can result in unauthorized ability to cause a hang
or frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 4.9
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-34303 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Optimizer). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Easily exploitable vulnerability allows low
privileged attacker with network access via
multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 6.5
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-34304 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component:
InnoDB). Supported versions that are affected are
8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily
exploitable vulnerability allows high privileged
attacker with network access via multiple
protocols to compromise MySQL Server. Successful
attacks of this vulnerability can result in
unauthorized ability to cause a hang or frequently
repeatable crash (complete DOS) of MySQL Server.
CVSS 3.1 Base Score 4.9 (Availability impacts).
CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-34308 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
JSON). Supported versions that are affected are
8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily
exploitable vulnerability allows low privileged
attacker with network access via multiple
protocols to compromise MySQL Server. Successful
attacks of this vulnerability can result in
unauthorized ability to cause a hang or frequently
repeatable crash (complete DOS) of MySQL Server.
CVSS 3.1 Base Score 6.5 (Availability impacts).
CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-34317 |
Vulnerability in the MySQL
Shell product of Oracle MySQL (component: Shell:
Core Client). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Easily exploitable vulnerability allows low
privileged attacker with logon to the
infrastructure where MySQL Shell executes to
compromise MySQL Shell. Successful attacks require
human interaction from a person other than the
attacker. Successful attacks of this vulnerability
can result in unauthorized ability to cause a hang
or frequently repeatable crash (complete DOS) of
MySQL Shell. CVSS 3.1 Base Score 5.0 (Availability
impacts). CVSS Vector:
(CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H). |
| CVE-2026-34318 |
Vulnerability in the MySQL
Shell product of Oracle MySQL (component: Shell:
Core Client). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Difficult to exploit vulnerability allows high
privileged attacker with network access via
multiple protocols to compromise MySQL Shell.
While the vulnerability is in MySQL Shell, attacks
may significantly impact additional products
(scope change). Successful attacks of this
vulnerability can result in unauthorized access to
critical data or complete access to all MySQL
Shell accessible data. CVSS 3.1 Base Score 5.8
(Confidentiality impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N). |
| CVE-2026-34319 |
Vulnerability in the MySQL
Shell product of Oracle MySQL (component: Shell:
Core Client). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Easily exploitable vulnerability allows low
privileged attacker with logon to the
infrastructure where MySQL Shell executes to
compromise MySQL Shell. Successful attacks require
human interaction from a person other than the
attacker. Successful attacks of this vulnerability
can result in unauthorized ability to cause a hang
or frequently repeatable crash (complete DOS) of
MySQL Shell. CVSS 3.1 Base Score 5.0 (Availability
impacts). CVSS Vector:
(CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H). |
| CVE-2026-35236 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component:
InnoDB). Supported versions that are affected are
8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily
exploitable vulnerability allows high privileged
attacker with network access via multiple
protocols to compromise MySQL Server. Successful
attacks of this vulnerability can result in
unauthorized ability to cause a hang or frequently
repeatable crash (complete DOS) of MySQL Server.
CVSS 3.1 Base Score 4.9 (Availability impacts).
CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-35237 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component:
InnoDB). Supported versions that are affected are
8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily
exploitable vulnerability allows high privileged
attacker with network access via multiple
protocols to compromise MySQL Server. Successful
attacks of this vulnerability can result in
unauthorized ability to cause a hang or frequently
repeatable crash (complete DOS) of MySQL Server.
CVSS 3.1 Base Score 4.9 (Availability impacts).
CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-35238 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component:
InnoDB). Supported versions that are affected are
8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily
exploitable vulnerability allows high privileged
attacker with network access via multiple
protocols to compromise MySQL Server. Successful
attacks of this vulnerability can result in
unauthorized ability to cause a hang or frequently
repeatable crash (complete DOS) of MySQL Server.
CVSS 3.1 Base Score 4.9 (Availability impacts).
CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-35239 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
DML). Supported versions that are affected are
8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily
exploitable vulnerability allows high privileged
attacker with network access via multiple
protocols to compromise MySQL Server. Successful
attacks of this vulnerability can result in
unauthorized ability to cause a hang or frequently
repeatable crash (complete DOS) of MySQL Server.
CVSS 3.1 Base Score 4.9 (Availability impacts).
CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-35240 |
Vulnerability in the MySQL
Server product of Oracle MySQL (component: Server:
Optimizer). Supported versions that are affected
are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0.
Easily exploitable vulnerability allows high
privileged attacker with network access via
multiple protocols to compromise MySQL Server.
Successful attacks of this vulnerability can
result in unauthorized ability to cause a hang or
frequently repeatable crash (complete DOS) of
MySQL Server. CVSS 3.1 Base Score 4.9
(Availability impacts). CVSS Vector:
(CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
| CVE-2026-40217 |
LiteLLM through 2026-04-08
allows remote attackers to execute arbitrary code
via bytecode rewriting at the
/guardrails/test_custom_code URI. |
| CVE-2026-40260 |
pypdf is a free and
open-source pure-python PDF library. In versions
prior to 6.10.0, manipulated XMP metadata entity
declarations can exhaust RAM. An attacker who
exploits this vulnerability can craft a PDF which
leads to large memory usage. This requires parsing
the XMP metadata. This issue has been fixed in
version 6.10.0. |
| CVE-2026-40962 |
FFmpeg before 8.1 has an
integer overflow and resultant out-of-bounds write
via CENC (Common Encryption) subsample data to
libavformat/mov.c. |
| CVE-2026-41168 |
pypdf is a free and
open-source pure-python PDF library. An attacker
who uses a vulnerability present in versions prior
to 6.10.1 can craft a PDF which leads to long
runtimes. This requires cross-reference streams
with wrong large `/Size` values or object streams
with wrong large `/N` values. This has been fixed
in pypdf 6.10.1. As a workaround, one may apply
the changes from the patch manually. |
| CVE-2026-41312 |
pypdf is a free and
open-source pure-python PDF library. An attacker
who uses a vulnerability present in versions prior
to 6.10.2 can craft a PDF which leads to the RAM
being exhausted. This requires accessing a stream
compressed using `/FlateDecode` with a
`/Predictor` unequal 1 and large predictor
parameters. This has been fixed in pypdf 6.10.2.
As a workaround, one may apply the changes from
the patch manually. |
| CVE-2026-41313 |
pypdf is a free and
open-source pure-python PDF library. An attacker
who uses a vulnerability present in versions prior
to 6.10.2 can craft a PDF which leads to long
runtimes. This requires loading a PDF with a large
trailer `/Size` value in incremental mode. This
has been fixed in pypdf 6.10.2. As a workaround,
one may apply the changes from the patch
manually. |
| CVE-2026-41314 |
pypdf is a free and
open-source pure-python PDF library. An attacker
who uses a vulnerability present in versions prior
to 6.10.2 can craft a PDF which leads to the RAM
being exhausted. This requires accessing an image
using `/FlateDecode` with large size values. This
has been fixed in pypdf 6.10.2. As a workaround,
one may apply the changes from the patch
manually. |
| CVE-2026-42198 |
pgjdbc is an open source
postgresql JDBC Driver. From version 42.2.0 to
before version 42.7.11, pgjdbc is vulnerable to a
client-side denial of service during SCRAM-SHA-256
authentication. A malicious server can instruct
the driver to perform SCRAM authentication with a
very large iteration count. With a large enough
value, the client spends an unbounded amount of
CPU time inside PBKDF2 before authentication can
fail. A single attempt ties up a CPU core.
Repeated or concurrent attempts exhaust client CPU
and can wedge connection pools. In affected
versions, loginTimeout did not fully mitigate this
problem. When loginTimeout expired, the caller
could stop waiting, but the worker thread
performing the connection attempt could continue
running and burning CPU inside the SCRAM PBKDF2
computation. This issue has been patched in
version 42.7.11. |
| CVE-2026-42203 |
LiteLLM is a proxy server (AI
Gateway) to call LLM APIs in OpenAI (or native)
format. From version 1.80.5 to before version
1.83.7, the POST /prompts/test endpoint accepted
user-supplied prompt templates and rendered them
without sandboxing. A crafted template could run
arbitrary code inside the LiteLLM Proxy process.
The endpoint only checks that the caller presents
a valid proxy API key, so any authenticated user
could reach it. Depending on how the proxy is
deployed, this could expose secrets in the process
environment (such as provider API keys or database
credentials) and allow commands to be run on the
host. This issue has been patched in version
1.83.7. |
| CVE-2026-42208
(KEV) |
LiteLLM is a proxy server (AI
Gateway) to call LLM APIs in OpenAI (or native)
format. From version 1.81.16 to before version
1.83.7, a database query used during proxy API key
checks mixed the caller-supplied key value into
the query text instead of passing it as a separate
parameter. An unauthenticated attacker could send
a specially crafted Authorization header to any
LLM API route (for example POST /chat/completions)
and reach this query through the proxy's
error-handling path. An attacker could read data
from the proxy's database and may be able to
modify it, leading to unauthorised access to the
proxy and the credentials it manages. This issue
has been patched in version 1.83.7. |
| CVE-2026-42271
(KEV) |
LiteLLM is a proxy server (AI
Gateway) to call LLM APIs in OpenAI (or native)
format. From version 1.74.2 to before version
1.83.7, two endpoints used to preview an MCP
server before saving it — POST
/mcp-rest/test/connection and POST
/mcp-rest/test/tools/list — accepted a full server
configuration in the request body, including the
command, args, and env fields used by the stdio
transport. When called with a stdio configuration,
the endpoints attempted to connect, which spawned
the supplied command as a subprocess on the proxy
host with the privileges of the proxy process. The
endpoints were gated only by a valid proxy API
key, with no role check. Any authenticated user —
including holders of low-privilege internal-user
keys — could therefore run arbitrary commands on
the host. This issue has been patched in version
1.83.7. |
| CVE-2026-43033 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
authencesn - Do not place hiseq at end of dst for
out-of-place decryption When decrypting data that
is not in-place (src != dst), there is no need to
save the high-order sequence bits in dst as it
could simply be re-copied from the source.
However, the data to be hashed need to be
rearranged accordingly. Thanks, |
| CVE-2026-43077 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
algif_aead - Fix minimum RX size check for
decryption The check for the minimum receive
buffer size did not take the tag size into account
during decryption. Fix this by adding the required
extra length. |
| CVE-2026-43078 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
af_alg - Fix page reassignment overflow in
af_alg_pull_tsgl When page reassignment was added
to af_alg_pull_tsgl the original loop wasn't
updated so it may try to reassign one more page
than necessary. Add the check to the reassignment
so that this does not happen. Also update the
comment which still refers to the obsolete offset
argument. |
| CVE-2026-43126 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
mixer: oss: Add card disconnect checkpoints ALSA
OSS mixer layer calls the kcontrol ops rather
individually, and pending calls might be not
always caught at disconnecting the device. For
avoiding the potential UAF scenarios, add sanity
checks of the card disconnection at each entry
point of OSS mixer accesses. The rwsem is taken
just before that check, hence the rest context
should be covered by that properly. |
| CVE-2026-43243 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amd/display: Add signal type check for dcn401
get_phyd32clk_src Trying to access link enc on a
dpia link will cause a crash otherwise |
| CVE-2026-43284 |
In the Linux kernel, the
following vulnerability has been resolved: xfrm:
esp: avoid in-place decrypt on shared skb frags
MSG_SPLICE_PAGES can attach pages from a pipe
directly to an skb. TCP marks such skbs with
SKBFL_SHARED_FRAG after skb_splice_from_iter(), so
later paths that may modify packet data can first
make a private copy. The IPv4/IPv6 datagram append
paths did not set this flag when splicing pages
into UDP skbs. That leaves an ESP-in-UDP packet
made from shared pipe pages looking like an
ordinary uncloned nonlinear skb. ESP input then
takes the no-COW fast path for uncloned skbs
without a frag_list and decrypts in place over
data that is not owned privately by the skb. Mark
IPv4/IPv6 datagram splice frags with
SKBFL_SHARED_FRAG, matching TCP. Also make ESP
input fall back to skb_cow_data() when the flag is
present, so ESP does not decrypt externally backed
frags in place. Private nonlinear skb frags still
use the existing fast path. This intentionally
does not change ESP output. In esp_output_head(),
the path that appends the ESP trailer to existing
skb tailroom without calling skb_cow_data() is not
reachable for nonlinear skbs: skb_tailroom()
returns zero when skb->data_len is nonzero,
while ESP tailen is positive. Thus ESP output will
either use the separate destination-frag path or
fall back to skb_cow_data(). |
| CVE-2026-43292 |
In the Linux kernel, the
following vulnerability has been resolved:
mm/vmalloc: prevent RCU stalls in
kasan_release_vmalloc_node When CONFIG_PAGE_OWNER
is enabled, freeing KASAN shadow pages during
vmalloc cleanup triggers expensive stack unwinding
that acquires RCU read locks. Processing a large
purge_list without rescheduling can cause the task
to hold CPU for extended periods (10+ seconds),
leading to RCU stalls and potential OOM
conditions. The issue manifests in
purge_vmap_node() ->
kasan_release_vmalloc_node() where iterating
through hundreds or thousands of vmap_area entries
and freeing their associated shadow pages causes:
rcu: INFO: rcu_preempt detected stalls on
CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node
(CPUs 0-1): P6229/1:b..l ... task:kworker/0:17
state:R running task stack:28840 pid:6229 ...
kasan_release_vmalloc_node+0x1ba/0xad0
mm/vmalloc.c:2299 purge_vmap_node+0x1ba/0xad0
mm/vmalloc.c:2299 Each call to
kasan_release_vmalloc() can free many pages, and
with page_owner tracking, each free triggers
save_stack() which performs stack unwinding under
RCU read lock. Without yielding, this creates an
unbounded RCU critical section. Add periodic
cond_resched() calls within the loop to allow: -
RCU grace periods to complete - Other tasks to run
- Scheduler to preempt when needed The fix uses
need_resched() for immediate response under load,
with a batch count of 32 as a guaranteed upper
bound to prevent worst-case stalls even under
light load. |
| CVE-2026-43294 |
In the Linux kernel, the
following vulnerability has been resolved: drm:
renesas: rz-du: mipi_dsi: fix kernel panic when
rebooting for some panels Since commit
56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP
for RZ/G2L") we may get the following kernel
panic, for some panels, when rebooting:
systemd-shutdown[1]: Rebooting. Call trace: ...
do_serror+0x28/0x68
el1h_64_error_handler+0x34/0x50
el1h_64_error+0x6c/0x70
rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
mipi_dsi_device_transfer+0x44/0x58
mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
ili9881c_unprepare+0x38/0x88
drm_panel_unprepare+0xbc/0x108 This happens for
panels that need to send MIPI-DSI commands in
their unprepare() callback. Since the MIPI-DSI
interface is stopped at that point,
rzg2l_mipi_dsi_host_transfer() triggers the kernel
panic. Fix by moving rzg2l_mipi_dsi_stop() to new
callback function
rzg2l_mipi_dsi_atomic_post_disable(). With this
change we now have the correct power-down/stop
sequence: systemd-shutdown[1]: Rebooting.
rzg2l-mipi-dsi 10850000.dsi:
rzg2l_mipi_dsi_atomic_disable(): entry
ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare():
entry rzg2l-mipi-dsi 10850000.dsi:
rzg2l_mipi_dsi_atomic_post_disable(): entry
reboot: Restarting system |
| CVE-2026-43298 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdgpu: Skip vcn poison irq release on VF VF
doesn't enable VCN poison irq in VCNv2.5. Skip
releasing it and avoid call trace during
deinitialization. [ 71.913601] [drm] clean up the
vf2pf work item [ 71.915088] ------------[ cut
here ]------------ [ 71.915092] WARNING: CPU: 3
PID: 1079 at
/tmp/amd.aFkFvSQl/amd/amdgpu/amdgpu_irq.c:641
amdgpu_irq_put+0xc6/0xe0 [amdgpu] [ 71.915355]
Modules linked in: amdgpu(OE-)
amddrm_ttm_helper(OE) amdttm(OE) amddrm_buddy(OE)
amdxcp(OE) amddrm_exec(OE) amd_sched(OE)
amdkcl(OE) drm_suballoc_helper drm_display_helper
cec rc_core i2c_algo_bit video wmi binfmt_misc
nls_iso8859_1 intel_rapl_msr intel_rapl_common
input_leds joydev serio_raw mac_hid qemu_fw_cfg
sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc
scsi_dh_alua efi_pstore ip_tables x_tables autofs4
btrfs blake2b_generic raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor
async_tx xor raid6_pq libcrc32c raid1 raid0
hid_generic crct10dif_pclmul crc32_pclmul
polyval_clmulni polyval_generic
ghash_clmulni_intel usbhid 8139too sha256_ssse3
sha1_ssse3 hid psmouse bochs i2c_i801 ahci
drm_vram_helper libahci i2c_smbus lpc_ich
drm_ttm_helper 8139cp mii ttm aesni_intel
crypto_simd cryptd [ 71.915484] CPU: 3 PID: 1079
Comm: rmmod Tainted: G OE 6.8.0-87-generic
#88~22.04.1-Ubuntu [ 71.915489] Hardware name: Red
Hat KVM/RHEL, BIOS 1.16.3-2.el9_5.1 04/01/2014 [
71.915492] RIP: 0010:amdgpu_irq_put+0xc6/0xe0
[amdgpu] [ 71.915768] Code: 75 84 b8 ea ff ff ff
eb d4 44 89 ea 48 89 de 4c 89 e7 e8 fd fc ff ff 5b
41 5c 41 5d 41 5e 5d 31 d2 31 f6 31 ff e9 55 30 3b
c7 <0f> 0b eb d4 b8 fe ff ff ff eb a8 e9 b7
3b 8a 00 66 2e 0f 1f 84 00 [ 71.915771] RSP:
0018:ffffcf0800eafa30 EFLAGS: 00010246 [
71.915775] RAX: 0000000000000000 RBX:
ffff891bda4b0668 RCX: 0000000000000000 [
71.915777] RDX: 0000000000000000 RSI:
0000000000000000 RDI: 0000000000000000 [
71.915779] RBP: ffffcf0800eafa50 R08:
0000000000000000 R09: 0000000000000000 [
71.915781] R10: 0000000000000000 R11:
0000000000000000 R12: ffff891bda480000 [
71.915782] R13: 0000000000000000 R14:
0000000000000001 R15: 0000000000000000 [
71.915792] FS: 000070cff87c4c40(0000)
GS:ffff893abfb80000(0000) knlGS:0000000000000000 [
71.915795] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 [ 71.915797] CR2:
00005fa13073e478 CR3: 000000010d634006 CR4:
0000000000770ef0 [ 71.915800] PKRU: 55555554 [
71.915802] Call Trace: [ 71.915805] <TASK> [
71.915809] vcn_v2_5_hw_fini+0x19e/0x1e0
[amdgpu] |
| CVE-2026-43299 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
do not ASSERT() when the fs flips RO inside
btrfs_repair_io_failure() [BUG] There is a bug
report that when btrfs hits ENOSPC error in a
critical path, btrfs flips RO (this part is
expected, although the ENOSPC bug still needs to
be addressed). The problem is after the RO flip,
if there is a read repair pending, we can hit the
ASSERT() inside btrfs_repair_io_failure() like the
following: BTRFS info (device vdc): relocating
block group 30408704 flags metadata|raid1
------------[ cut here ]------------ BTRFS:
Transaction aborted (error -28) WARNING:
fs/btrfs/extent-tree.c:3235 at
__btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1:
btrfs/383844 Modules linked in: kvm_intel kvm
irqbypass [...] ---[ end trace 0000000000000000
]--- BTRFS info (device vdc state EA): 2 enospc
errors during balance BTRFS info (device vdc state
EA): balance: ended with status: -30 BTRFS error
(device vdc state EA): parent transid verify
failed on logical 30556160 mirror 2 wanted 8 found
6 BTRFS error (device vdc state EA): bdev
/dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt
10, gen 0 [...] assertion failed:
!(fs_info->sb->s_flags & SB_RDONLY) ::
0, in fs/btrfs/bio.c:938 ------------[ cut here
]------------ assertion failed:
!(fs_info->sb->s_flags & SB_RDONLY) ::
0, in fs/btrfs/bio.c:938 kernel BUG at
fs/btrfs/bio.c:938! Oops: invalid opcode: 0000
[#1] SMP NOPTI CPU: 0 UID: 0 PID: 868 Comm:
kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788
PREEMPT(full) Tainted: [W]=WARN, [N]=TEST Hardware
name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org
04/01/2014 Workqueue: btrfs-endio
simple_end_io_work RIP:
0010:btrfs_repair_io_failure.cold+0xb2/0x120 RSP:
0000:ffffc90001d2bcf0 EFLAGS: 00010246 RAX:
0000000000000051 RBX: 0000000000001000 RCX:
0000000000000000 RDX: 0000000000000000 RSI:
ffffffff8305cf42 RDI: 00000000ffffffff RBP:
0000000000000002 R08: 00000000fffeffff R09:
ffffffff837fa988 R10: ffffffff8327a9e0 R11:
6f69747265737361 R12: ffff88813018d310 R13:
ffff888168b8a000 R14: ffffc90001d2bd90 R15:
ffff88810a169000 FS: 0000000000000000(0000)
GS:ffff8885e752c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
------------[ cut here ]------------ [CAUSE] The
cause of -ENOSPC error during the test case
btrfs/124 is still unknown, although it's known
that we still have cases where metadata can be
over-committed but can not be fulfilled correctly,
thus if we hit such ENOSPC error inside a critical
path, we have no choice but abort the current
transaction. This will mark the fs read-only. The
problem is inside the btrfs_repair_io_failure()
path that we require the fs not to be mount
read-only. This is normally fine, but if we are
doing a read-repair meanwhile the fs flips RO due
to a critical error, we can enter
btrfs_repair_io_failure() with super block set to
read-only, thus triggering the above crash. [FIX]
Just replace the ASSERT() with a proper return if
the fs is already read-only. |
| CVE-2026-43301 |
In the Linux kernel, the
following vulnerability has been resolved: media:
chips-media: wave5: Fix PM runtime usage count
underflow Replace pm_runtime_put_sync() with
pm_runtime_dont_use_autosuspend() in the remove
path to properly pair with
pm_runtime_use_autosuspend() from probe. This
allows pm_runtime_disable() to handle reference
count cleanup correctly regardless of current
suspend state. The driver calls
pm_runtime_put_sync() unconditionally in remove,
but the device may already be suspended due to
autosuspend configured in probe. When autosuspend
has already suspended the device, the usage count
is 0, and pm_runtime_put_sync() decrements it to
-1. This causes the following warning on module
unload: ------------[ cut here ]------------
WARNING: CPU: 1 PID: 963 at kernel/kthread.c:1430
kthread_destroy_worker+0x84/0x98 ... vdec
30210000.video-codec: Runtime PM usage count
underflow! |
| CVE-2026-43303 |
In the Linux kernel, the
following vulnerability has been resolved:
mm/page_alloc: clear page->private in
free_pages_prepare() Several subsystems (slub,
shmem, ttm, etc.) use page->private but don't
clear it before freeing pages. When these pages
are later allocated as high-order pages and split
via split_page(), tail pages retain stale
page->private values. This causes a
use-after-free in the swap subsystem. The swap
code uses page->private to track swap count
continuations, assuming freshly allocated pages
have page->private == 0. When stale values are
present, swap_count_continued() incorrectly
assumes the continuation list is valid and
iterates over uninitialized page->lru
containing LIST_POISON values, causing a crash:
KASAN: maybe wild-memory-access in range
[0xdead000000000100-0xdead000000000107] RIP:
0010:__do_sys_swapoff+0x1151/0x1860 Fix this by
clearing page->private in free_pages_prepare(),
ensuring all freed pages have clean state
regardless of previous use. |
| CVE-2026-43305 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amd/display: Fix mismatched unlock for DMUB HW
lock in HWSS fast path [Why] The evaluation for
whether we need to use the DMUB HW lock isn't the
same as whether we need to unlock which results in
a hang when the fast path is used for ASIC without
FAMS support. [How] Store a flag that indicates
whether we should use the lock and use that same
flag to specify whether unlocking is
needed. |
| CVE-2026-43306 |
In the Linux kernel, the
following vulnerability has been resolved: bpf:
crypto: Use the correct destructor kfunc type With
CONFIG_CFI enabled, the kernel strictly enforces
that indirect function calls use a function
pointer type that matches the target function. I
ran into the following type mismatch when running
BPF self-tests: CFI failure at
bpf_obj_free_fields+0x190/0x238 (target:
bpf_crypto_ctx_release+0x0/0x94; expected type:
0xa488ebfc) Internal error: Oops - CFI:
00000000f2008228 [#1] SMP ... As
bpf_crypto_ctx_release() is also used in BPF
programs and using a void pointer as the argument
would make the verifier unhappy, add a simple stub
function with the correct type and register it as
the destructor kfunc instead. |
| CVE-2026-43308 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
don't BUG() on unexpected delayed ref type in
run_one_delayed_ref() There is no need to BUG(),
we can just return an error and log an error
message. |
| CVE-2026-43309 |
In the Linux kernel, the
following vulnerability has been resolved: md
raid: fix hang when stopping arrays with metadata
through dm-raid When using device-mapper's dm-raid
target, stopping a RAID array can cause the system
to hang under specific conditions. This occurs
when: - A dm-raid managed device tree is suspended
from top to bottom (the top-level RAID device is
suspended first, followed by its underlying
metadata and data devices) - The top-level RAID
device is then removed Removing the top-level
device triggers a hang in the following sequence:
the dm-raid destructor calls md_stop(), which
tries to flush the write-intent bitmap by writing
to the metadata sub-devices. However, these
devices are already suspended, making them unable
to complete the write-intent operations and
causing an indefinite block. Fix: - Prevent bitmap
flushing when md_stop() is called from dm-raid
destructor context and avoid a
quiescing/unquescing cycle which could also cause
I/O - Still allow write-intent bitmap flushing
when called from dm-raid suspend context This
ensures that RAID array teardown can complete
successfully even when the underlying devices are
in a suspended state. This second patch uses
md_is_rdwr() to distinguish between suspend and
destructor paths as elaborated on above. |
| CVE-2026-43310 |
In the Linux kernel, the
following vulnerability has been resolved: media:
verisilicon: Avoid G2 bus error while decoding
H.264 and HEVC For the i.MX8MQ platform, there is
a hardware limitation: the g1 VPU and g2 VPU
cannot decode simultaneously; otherwise, it will
cause below bus error and produce corrupted
pictures, even potentially lead to system hang. [
110.527986] hantro-vpu 38310000.video-codec: frame
decode timed out. [ 110.583517] hantro-vpu
38310000.video-codec: bus error detected.
Therefore, it is necessary to ensure that g1 and
g2 operate alternately. This allows for successful
multi-instance decoding of H.264 and HEVC. To
achieve this, g1 and g2 share the same
v4l2_m2m_dev, and then the v4l2_m2m_dev can handle
the scheduling. |
| CVE-2026-43311 |
In the Linux kernel, the
following vulnerability has been resolved:
soc/tegra: pmc: Fix unsafe generic_handle_irq()
call Currently, when resuming from system suspend
on Tegra platforms, the following warning is
observed: WARNING: CPU: 0 PID: 14459 at
kernel/irq/irqdesc.c:666 Call trace:
handle_irq_desc+0x20/0x58 (P)
tegra186_pmc_wake_syscore_resume+0xe4/0x15c
syscore_resume+0x3c/0xb8
suspend_devices_and_enter+0x510/0x540
pm_suspend+0x16c/0x1d8 The warning occurs because
generic_handle_irq() is being called from a
non-interrupt context which is considered as
unsafe. Fix this warning by deferring
generic_handle_irq() call to an IRQ work which
gets executed in hard IRQ context where
generic_handle_irq() can be called safely. When
PREEMPT_RT kernels are used, regular IRQ work
(initialized with init_irq_work) is deferred to
run in per-CPU kthreads in preemptible context
rather than hard IRQ context. Hence, use the
IRQ_WORK_INIT_HARD variant so that with PREEMPT_RT
kernels, the IRQ work is processed in hardirq
context instead of being deferred to a thread
which is required for calling
generic_handle_irq(). On non-PREEMPT_RT kernels,
both init_irq_work() and IRQ_WORK_INIT_HARD()
execute in IRQ context, so this change has no
functional impact for standard kernel
configurations. [treding@nvidia.com: miscellaneous
cleanups] |
| CVE-2026-43321 |
In the Linux kernel, the
following vulnerability has been resolved: bpf:
Properly mark live registers for indirect jumps
For a `gotox rX` instruction the rX register
should be marked as used in the
compute_insn_live_regs() function. Fix
this. |
| CVE-2026-43331 |
In the Linux kernel, the
following vulnerability has been resolved:
x86/kexec: Disable KCOV instrumentation after
load_segments() The load_segments() function
changes segment registers, invalidating GS base
(which KCOV relies on for per-cpu data). When
CONFIG_KCOV is enabled, any subsequent
instrumented C code call (e.g.
native_gdt_invalidate()) begins crashing the
kernel in an endless loop. To reproduce the
problem, it's sufficient to do kexec on a
KCOV-instrumented kernel: $ kexec -l
/boot/otherKernel $ kexec -e The real-world
context for this problem is enabling crash dump
collection in syzkaller. For this, the tool loads
a panic kernel before fuzzing and then calls
makedumpfile after the panic. This workflow
requires both CONFIG_KEXEC and CONFIG_KCOV to be
enabled simultaneously. Adding safeguards directly
to the KCOV fast-path (__sanitizer_cov_trace_pc())
is also undesirable as it would introduce an extra
performance overhead. Disabling instrumentation
for the individual functions would be too fragile,
so disable KCOV instrumentation for the entire
machine_kexec_64.c and physaddr.c. If
coverage-guided fuzzing ever needs these
components in the future, other approaches should
be considered. The problem is not relevant for 32
bit kernels as CONFIG_KCOV is not supported there.
[ bp: Space out comment for better readability.
] |
| CVE-2026-43344 |
In the Linux kernel, the
following vulnerability has been resolved:
perf/x86/intel/uncore: Fix die ID init and look up
bugs In snbep_pci2phy_map_init(), in the
nr_node_ids > 8 path, uncore_device_to_die()
may return -1 when all CPUs associated with the
UBOX device are offline. Remove the
WARN_ON_ONCE(die_id == -1) check for two reasons:
- The current code breaks out of the loop. This is
incorrect because pci_get_device() does not
guarantee iteration in domain or bus order, so
additional UBOX devices may be skipped during the
scan. - Returning -EINVAL is incorrect, since
marking offline buses with die_id == -1 is
expected and should not be treated as an error.
Separately, when NUMA is disabled on a
NUMA-capable platform, pcibus_to_node() returns
NUMA_NO_NODE, causing uncore_device_to_die() to
return -1 for all PCI devices. As a result,
spr_update_device_location(), used on Intel SPR
and EMR, ignores the corresponding PMON units and
does not add them to the RB tree. Fix this by
using uncore_pcibus_to_dieid(), which retrieves
topology from the UBOX GIDNIDMAP register and
works regardless of whether NUMA is enabled in
Linux. This requires snbep_pci2phy_map_init() to
be added in spr_uncore_pci_init(). Keep
uncore_device_to_die() only for the nr_node_ids
> 8 case, where NUMA is expected to be
enabled. |
| CVE-2026-43352 |
In the Linux kernel, the
following vulnerability has been resolved: i3c:
mipi-i3c-hci: Correct RING_CTRL_ABORT handling in
DMA dequeue The logic used to abort the DMA ring
contains several flaws: 1. The driver
unconditionally issues a ring abort even when the
ring has already stopped. 2. The completion used
to wait for abort completion is never
re-initialized, resulting in incorrect wait
behavior. 3. The abort sequence unintentionally
clears RING_CTRL_ENABLE, which resets hardware
ring pointers and disrupts the controller state.
4. If the ring is already stopped, the abort
operation should be considered successful without
attempting further action. Fix the abort handling
by checking whether the ring is running before
issuing an abort, re-initializing the completion
when needed, ensuring that RING_CTRL_ENABLE
remains asserted during abort, and treating an
already stopped ring as a successful
condition. |
| CVE-2026-43353 |
In the Linux kernel, the
following vulnerability has been resolved: i3c:
mipi-i3c-hci: Fix race in DMA ring dequeue The HCI
DMA dequeue path (hci_dma_dequeue_xfer()) may be
invoked for multiple transfers that timeout around
the same time. However, the function is not
serialized and can race with itself. When a
timeout occurs, hci_dma_dequeue_xfer() stops the
ring, processes incomplete transfers, and then
restarts the ring. If another timeout triggers a
parallel call into the same function, the two
instances may interfere with each other - stopping
or restarting the ring at unexpected times. Add a
mutex so that hci_dma_dequeue_xfer() is serialized
with respect to itself. |
| CVE-2026-43398 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdgpu: add upper bound check on user inputs
in wait ioctl Huge input values in
amdgpu_userq_wait_ioctl can lead to a OOM and
could be exploited. So check these input value
against AMDGPU_USERQ_MAX_HANDLES which is big
enough value for genuine use cases and could
potentially avoid OOM. v2: squash in Srini's fix
(cherry picked from commit
fcec012c664247531aed3e662f4280ff804d1476) |
| CVE-2026-43400 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdgpu: add upper bound check on user inputs
in signal ioctl Huge input values in
amdgpu_userq_signal_ioctl can lead to a OOM and
could be exploited. So check these input value
against AMDGPU_USERQ_MAX_HANDLES which is big
enough value for genuine use cases and could
potentially avoid OOM. (cherry picked from commit
be267e15f99bc97cbe202cd556717797cdcf79a5) |
| CVE-2026-43410 |
In the Linux kernel, the
following vulnerability has been resolved:
firmware: stratix10-rsu: Fix NULL pointer
dereference when RSU is disabled When the Remote
System Update (RSU) isn't enabled in the First
Stage Boot Loader (FSBL), the driver encounters a
NULL pointer dereference when excute
svc_normal_to_secure_thread() thread, resulting in
a kernel panic: Unable to handle kernel NULL
pointer dereference at virtual address
0000000000000008 Mem abort info: ... Data abort
info: ... [0000000000000008] user address but
active_mm is swapper Internal error: Oops:
0000000096000004 [#1] SMP Modules linked in: CPU:
0 UID: 0 PID: 79 Comm: svc_smc_hvc_thr Not tainted
6.19.0-rc8-yocto-standard+ #59 PREEMPT Hardware
name: SoCFPGA Stratix 10 SoCDK (DT) pstate:
60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--) pc :
svc_normal_to_secure_thread+0x38c/0x990 lr :
svc_normal_to_secure_thread+0x144/0x990 ... Call
trace: svc_normal_to_secure_thread+0x38c/0x990 (P)
kthread+0x150/0x210 ret_from_fork+0x10/0x20 Code:
97cfc113 f9400260 aa1403e1 f9400400 (f9400402)
---[ end trace 0000000000000000 ]--- The issue
occurs because rsu_send_async_msg() fails when RSU
is not enabled in firmware, causing the channel to
be freed via stratix10_svc_free_channel().
However, the probe function continues execution
and registers svc_normal_to_secure_thread(), which
subsequently attempts to access the already-freed
channel, triggering the NULL pointer dereference.
Fix this by properly cleaning up the async client
and returning early on failure, preventing the
thread from being used with an invalid
channel. |
| CVE-2026-43416 |
In the Linux kernel, the
following vulnerability has been resolved:
powerpc, perf: Check that current->mm is alive
before getting user callchain It may happen that
mm is already released, which leads to kernel
panic. This adds the NULL check for
current->mm, similarly to commit 20afc60f892d
("x86, perf: Check that current->mm is alive
before getting user callchain"). I was getting
this panic when running a profiling BPF program
(profile.py from bcc-tools): [26215.051935] Kernel
attempted to read user page (588) - exploit
attempt? (uid: 0) [26215.051950] BUG: Kernel NULL
pointer dereference on read at 0x00000588
[26215.051952] Faulting instruction address:
0xc00000000020fac0 [26215.051957] Oops: Kernel
access of bad area, sig: 11 [#1] [...]
[26215.052049] Call Trace: [26215.052050]
[c000000061da6d30] [c00000000020fc10]
perf_callchain_user_64+0x2d0/0x490 (unreliable)
[26215.052054] [c000000061da6dc0]
[c00000000020f92c] perf_callchain_user+0x1c/0x30
[26215.052057] [c000000061da6de0]
[c0000000005ab2a0] get_perf_callchain+0x100/0x360
[26215.052063] [c000000061da6e70]
[c000000000573bc8] bpf_get_stackid+0x88/0xf0
[26215.052067] [c000000061da6ea0]
[c008000000042258]
bpf_prog_16d4ab9ab662f669_do_perf_event+0xf8/0x274
[...] In addition, move storing the top-level
stack entry to generic perf_callchain_user to make
sure the top-evel entry is always captured, even
if current->mm is NULL. [Maddy: fixed message
to avoid checkpatch format style error] |
| CVE-2026-43443 |
In the Linux kernel, the
following vulnerability has been resolved: ASoC:
amd: acp-mach-common: Add missing error check for
clock acquisition The acp_card_rt5682_init() and
acp_card_rt5682s_init() functions did not check
the return values of clk_get(). This could lead to
a kernel crash when the invalid pointers are later
dereferenced by clock core functions. Fix this by:
1. Changing clk_get() to the device-managed
devm_clk_get(). 2. Adding IS_ERR() checks
immediately after each clock acquisition. |
| CVE-2026-43463 |
In the Linux kernel, the
following vulnerability has been resolved: rxrpc,
afs: Fix missing error pointer check after
rxrpc_kernel_lookup_peer()
rxrpc_kernel_lookup_peer() can also return error
pointers in addition to NULL, so just checking for
NULL is not sufficient. Fix this by: (1) Changing
rxrpc_kernel_lookup_peer() to return -ENOMEM
rather than NULL on allocation failure. (2) Making
the callers in afs use IS_ERR() and PTR_ERR() to
pass on the error code returned. |
| CVE-2026-43464 |
In the Linux kernel, the
following vulnerability has been resolved:
net/mlx5e: RX, Fix XDP multi-buf frag counting for
legacy RQ XDP multi-buf programs can modify the
layout of the XDP buffer when the program calls
bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The
referenced commit in the fixes tag corrected the
assumption in the mlx5 driver that the XDP buffer
layout doesn't change during a program execution.
However, this fix introduced another issue: the
dropped fragments still need to be counted on the
driver side to avoid page fragment reference
counting issues. Such issue can be observed with
the test_xdp_native_adjst_tail_shrnk_data selftest
when using a payload of 3600 and shrinking by 256
bytes (an upcoming selftest patch): the last
fragment gets released by the XDP code but doesn't
get tracked by the driver. This results in a
negative pp_ref_count during page release and the
following splat: WARNING:
include/net/page_pool/helpers.h:297 at
mlx5e_page_release_fragmented.isra.0+0x4a/0x50
[mlx5_core], CPU#12: ip/3137 Modules linked in:
[...] CPU: 12 UID: 0 PID: 3137 Comm: ip Not
tainted 6.19.0-rc3+ #12 NONE Hardware name: QEMU
Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org
04/01/2014 RIP:
0010:mlx5e_page_release_fragmented.isra.0+0x4a/0x50
[mlx5_core] [...] Call Trace: <TASK>
mlx5e_dealloc_rx_wqe+0xcb/0x1a0 [mlx5_core]
mlx5e_free_rx_descs+0x7f/0x110 [mlx5_core]
mlx5e_close_rq+0x50/0x60 [mlx5_core]
mlx5e_close_queues+0x36/0x2c0 [mlx5_core]
mlx5e_close_channel+0x1c/0x50 [mlx5_core]
mlx5e_close_channels+0x45/0x80 [mlx5_core]
mlx5e_safe_switch_params+0x1a5/0x230 [mlx5_core]
mlx5e_change_mtu+0xf3/0x2f0 [mlx5_core]
netif_set_mtu_ext+0xf1/0x230
do_setlink.isra.0+0x219/0x1180
rtnl_newlink+0x79f/0xb60
rtnetlink_rcv_msg+0x213/0x3a0
netlink_rcv_skb+0x48/0xf0
netlink_unicast+0x24a/0x350
netlink_sendmsg+0x1ee/0x410
__sock_sendmsg+0x38/0x60
____sys_sendmsg+0x232/0x280
___sys_sendmsg+0x78/0xb0 __sys_sendmsg+0x5f/0xb0
[...] do_syscall_64+0x57/0xc50 This patch fixes
the issue by doing page frag counting on all the
original XDP buffer fragments for all relevant XDP
actions (XDP_TX , XDP_REDIRECT and XDP_PASS). This
is basically reverting to the original counting
before the commit in the fixes tag. As frag_page
is still pointing to the original tail, the
nr_frags parameter to xdp_update_skb_frags_info()
needs to be calculated in a different way to
reflect the new nr_frags. |
| CVE-2026-43465 |
In the Linux kernel, the
following vulnerability has been resolved:
net/mlx5e: RX, Fix XDP multi-buf frag counting for
striding RQ XDP multi-buf programs can modify the
layout of the XDP buffer when the program calls
bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The
referenced commit in the fixes tag corrected the
assumption in the mlx5 driver that the XDP buffer
layout doesn't change during a program execution.
However, this fix introduced another issue: the
dropped fragments still need to be counted on the
driver side to avoid page fragment reference
counting issues. The issue was discovered by the
drivers/net/xdp.py selftest, more specifically the
test_xdp_native_tx_mb: - The mlx5 driver allocates
a page_pool page and initializes it with a frag
counter of 64 (pp_ref_count=64) and the internal
frag counter to 0. - The test sends one packet
with no payload. - On RX
(mlx5e_skb_from_cqe_mpwrq_nonlinear()), mlx5
configures the XDP buffer with the packet data
starting in the first fragment which is the page
mentioned above. - The XDP program runs and calls
bpf_xdp_pull_data() which moves the header into
the linear part of the XDP buffer. As the packet
doesn't contain more data, the program drops the
tail fragment since it no longer contains any
payload (pp_ref_count=63). - mlx5 device skips
counting this fragment. Internal frag counter
remains 0. - mlx5 releases all 64 fragments of the
page but page pp_ref_count is 63 => negative
reference counting error. Resulting splat during
the test: WARNING: CPU: 0 PID: 188225 at
./include/net/page_pool/helpers.h:297
mlx5e_page_release_fragmented.isra.0+0xbd/0xe0
[mlx5_core] Modules linked in: [...] CPU: 0 UID: 0
PID: 188225 Comm: ip Not tainted
6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_44
#1 NONE Hardware name: QEMU Standard PC (Q35 +
ICH9, 2009), BIOS
rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org
04/01/2014 RIP:
0010:mlx5e_page_release_fragmented.isra.0+0xbd/0xe0
[mlx5_core] [...] Call Trace: <TASK>
mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core]
mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core]
mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core]
mlx5e_close_rq+0x78/0xa0 [mlx5_core]
mlx5e_close_queues+0x46/0x2a0 [mlx5_core]
mlx5e_close_channel+0x24/0x90 [mlx5_core]
mlx5e_close_channels+0x5d/0xf0 [mlx5_core]
mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core]
mlx5e_change_mtu+0x11d/0x490 [mlx5_core]
mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core]
netif_set_mtu_ext+0xfc/0x240
do_setlink.isra.0+0x226/0x1100
rtnl_newlink+0x7a9/0xba0
rtnetlink_rcv_msg+0x220/0x3c0
netlink_rcv_skb+0x4b/0xf0
netlink_unicast+0x255/0x380
netlink_sendmsg+0x1f3/0x420
__sock_sendmsg+0x38/0x60
____sys_sendmsg+0x1e8/0x240
___sys_sendmsg+0x7c/0xb0 [...]
__sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xc70
The problem applies for XDP_PASS as well which is
handled in a different code path in the driver.
This patch fixes the issue by doing page frag
counting on all the original XDP buffer fragments
for all relevant XDP actions (XDP_TX ,
XDP_REDIRECT and XDP_PASS). This is basically
reverting to the original counting before the
commit in the fixes tag. As frag_page is still
pointing to the original tail, the nr_frags
parameter to xdp_update_skb_frags_info() needs to
be calculated in a different way to reflect the
new nr_frags. |
| CVE-2026-43474 |
In the Linux kernel, the
following vulnerability has been resolved: fs:
init flags_valid before calling vfs_fileattr_get
syzbot reported a uninit-value bug in [1]. Similar
to the "*get" context where the kernel's internal
file_kattr structure is initialized before calling
vfs_fileattr_get(), we should use the same
mechanism when using fa. [1] BUG: KMSAN:
uninit-value in fuse_fileattr_get+0xeb4/0x1450
fs/fuse/ioctl.c:517 fuse_fileattr_get+0xeb4/0x1450
fs/fuse/ioctl.c:517 vfs_fileattr_get
fs/file_attr.c:94 [inline] __do_sys_file_getattr
fs/file_attr.c:416 [inline] Local variable fa.i
created at: __do_sys_file_getattr
fs/file_attr.c:380 [inline]
__se_sys_file_getattr+0x8c/0xbd0
fs/file_attr.c:372 |
| CVE-2026-43485 |
In the Linux kernel, the
following vulnerability has been resolved:
nouveau/gsp: drop WARN_ON in ACPI probes These
WARN_ONs seem to trigger a lot, and we don't seem
to have a plan to fix them, so just drop them, as
they are most likely harmless. |
| CVE-2026-43490 |
In the Linux kernel, the
following vulnerability has been resolved: ksmbd:
validate inherited ACE SID length
smb_inherit_dacl() walks the parent directory DACL
loaded from the security descriptor xattr. It
verifies that each ACE contains the fixed SID
header before using it, but does not verify that
the variable-length SID described by
sid.num_subauth is fully contained in the ACE. A
malformed inheritable ACE can advertise more
subauthorities than are present in the ACE.
compare_sids() may then read past the ACE.
smb_set_ace() also clamps the copied destination
SID, but used the unchecked source SID count to
compute the inherited ACE size. That could advance
the temporary inherited ACE buffer pointer and
nt_size accounting past the allocated buffer. Fix
this by validating the parent ACE SID count and
SID length before using the SID during
inheritance. Compute the inherited ACE size from
the copied SID so the size matches the bounded
destination SID. Reject the inherited DACL if size
accumulation would overflow smb_acl.size or the
security descriptor allocation size. |
| CVE-2026-43491 |
In the Linux kernel, the
following vulnerability has been resolved: net:
qrtr: ns: Limit the maximum server registration
per node Current code does no bound checking on
the number of servers added per node. A malicious
client can flood NEW_SERVER messages and exhaust
memory. Fix this issue by limiting the maximum
number of server registrations to 256 per node. If
the NEW_SERVER message is received for an old
port, then don't restrict it as it will get
replaced. While at it, also rate limit the error
messages in the failure path of qrtr_ns_worker().
Note that the limit of 256 is chosen based on the
current platform requirements. If requirement
changes in the future, this limit can be
increased. |
| CVE-2026-43492 |
In the Linux kernel, the
following vulnerability has been resolved:
lib/crypto: mpi: Fix integer underflow in
mpi_read_raw_from_sgl() Yiming reports an integer
underflow in mpi_read_raw_from_sgl() when
subtracting "lzeros" from the unsigned "nbytes".
For this to happen, the scatterlist "sgl" needs to
occupy more bytes than the "nbytes" parameter and
the first "nbytes + 1" bytes of the scatterlist
must be zero. Under these conditions, the while
loop iterating over the scatterlist will count
more zeroes than "nbytes", subtract the number of
zeroes from "nbytes" and cause the underflow. When
commit 2d4d1eea540b ("lib/mpi: Add mpi sgl
helpers") originally introduced the bug, it
couldn't be triggered because all callers of
mpi_read_raw_from_sgl() passed a scatterlist whose
length was equal to "nbytes". However since commit
63ba4d67594a ("KEYS: asymmetric: Use new crypto
interface without scatterlists"), the underflow
can now actually be triggered. When invoking a
KEYCTL_PKEY_ENCRYPT system call with a larger
"out_len" than "in_len" and filling the "in"
buffer with zeroes, crypto_akcipher_sync_prep()
will create an all-zero scatterlist used for both
the "src" and "dst" member of struct
akcipher_request and thereby fulfil the conditions
to trigger the bug: sys_keyctl()
keyctl_pkey_e_d_s() asymmetric_key_eds_op()
software_key_eds_op()
crypto_akcipher_sync_encrypt()
crypto_akcipher_sync_prep()
crypto_akcipher_encrypt() rsa_enc()
mpi_read_raw_from_sgl() To the user this will be
visible as a DoS as the kernel spins forever,
causing soft lockup splats as a side effect. Fix
it. |
| CVE-2026-43493 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
pcrypt - Fix handling of MAY_BACKLOG requests
MAY_BACKLOG requests can return EBUSY. Handle them
by checking for that value and filtering out
EINPROGRESS notifications. |
| CVE-2026-43494 |
In the Linux kernel, the
following vulnerability has been resolved:
net/rds: reset op_nents when zerocopy page pin
fails When iov_iter_get_pages2() fails in
rds_message_zcopy_from_user(), the pinned pages
are released with put_page(), and
rm->data.op_mmp_znotifier is cleared. But we
fail to properly clear rm->data.op_nents. Later
when rds_message_purge() is called from
rds_sendmsg() the cleanup loop iterates over the
incorrectly non zero number of op_nents and frees
them again. Fix this by properly resetting
op_nents when it should be in
rds_message_zcopy_from_user(). |
| CVE-2026-43495 |
In the Linux kernel, the
following vulnerability has been resolved: net:
wwan: t7xx: validate port_count against message
length in t7xx_port_enum_msg_handler
t7xx_port_enum_msg_handler() uses the
modem-supplied port_count field as a loop bound
over port_msg->data[] without checking that the
message buffer contains sufficient data. A modem
sending port_count=65535 in a 12-byte buffer
triggers a slab-out-of-bounds read of up to 262140
bytes. Add a sizeof(*port_msg) check before
accessing the port message header fields to guard
against undersized messages. Add a struct_size()
check after extracting port_count and before the
loop. In t7xx_parse_host_rt_data(), guard the
rt_feature header read with a remaining-buffer
check before accessing data_len, validate
feat_data_len against the actual remaining buffer
to prevent OOB reads and signed integer overflow
on offset. Pass msg_len from both call sites:
skb->len at the DPMAIF path after skb_pull(),
and the validated feat_data_len at the handshake
path. |
| CVE-2026-43496 |
In the Linux kernel, the
following vulnerability has been resolved:
net/sched: sch_red: Replace direct dequeue call
with peek and qdisc_dequeue_peeked When red qdisc
has children (eg qfq qdisc) whose peek() callback
is qdisc_peek_dequeued(), we could get a kernel
panic. When the parent of such qdiscs (eg
illustrated in patch #3 as tbf) wants to retrieve
an skb from its child (red in this case), it will
do the following: 1a. do a peek() - and when
sensing there's an skb the child can offer, then -
the child in this case(red) calls its child's
(qfq) peek. qfq does the right thing and will
return the gso_skb queue packet. Note: if there
wasnt a gso_skb entry then qfq will store it
there. 1b. invoke a dequeue() on the child (red).
And herein lies the problem. - red will call the
child's dequeue() which will essentially just try
to grab something of qfq's queue. [ 78.667668][
T363] KASAN: null-ptr-deref in range
[0x0000000000000048-0x000000000000004f] [
78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm:
ping Not tainted
7.1.0-rc1-00033-g46f74a3f7d57-dirty #790
PREEMPT(full) [ 78.668263][ T363] Hardware name:
Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][
T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq]
[ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48
c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b
48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03
<80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b
48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP:
0018:ffff88810de573e0 EFLAGS: 00010216 [
78.669533][ T363] RAX: dffffc0000000000 RBX:
0000000000000000 RCX: 0000000000000000 [
78.669790][ T363] RDX: 0000000000000009 RSI:
0000000000000004 RDI: 0000000000000048 [
78.670044][ T363] RBP: ffff888110dc4000 R08:
ffffffffb1b0885a R09: fffffbfff6ba9078 [
78.670297][ T363] R10: 0000000000000003 R11:
ffff888110e31c80 R12: 0000001880000000 [
78.670560][ T363] R13: ffff888110dc4150 R14:
ffff888110dc42b8 R15: 0000000000000200 [
78.670814][ T363] FS: 00007f66a8f09c40(0000)
GS:ffff888163428000(0000) knlGS:0000000000000000 [
78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 [ 78.671324][ T363] CR2:
000055db4c6a30a8 CR3: 000000010da67000 CR4:
0000000000750ef0 [ 78.671585][ T363] PKRU:
55555554 [ 78.671713][ T363] Call Trace: [
78.671843][ T363] <TASK> [ 78.671936][ T363]
? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [
78.672148][ T363] ? __pfx__printk+0x10/0x10 [
78.672322][ T363] ?
srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][
T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [
78.672706][ T363] ?
srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][
T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][
T363] red_dequeue+0x65/0x270 [sch_red] [
78.673217][ T363] ?
srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][
T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [
78.673566][ T363] __qdisc_run+0x169/0x1900 The
right thing to do in #1b is to grab the skb off
gso_skb queue. This patchset fixes that issue by
changing #1b to use qdisc_dequeue_peeked() method
instead. |
| CVE-2026-43497 |
In the Linux kernel, the
following vulnerability has been resolved: fbdev:
udlfb: add vm_ops to dlfb_ops_mmap to prevent
use-after-free dlfb_ops_mmap() uses
remap_pfn_range() to map vmalloc framebuffer pages
to userspace but sets no vm_ops on the VMA. This
means the kernel cannot track active mmaps. When
dlfb_realloc_framebuffer() replaces the backing
buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs
are not invalidated. On USB disconnect,
dlfb_ops_destroy() calls vfree() on the old pages
while userspace PTEs still reference them,
resulting in a use-after-free: the process retains
read/write access to freed kernel pages. Add
vm_operations_struct with open/close callbacks
that maintain an atomic mmap_count on struct
dlfb_data. In dlfb_realloc_framebuffer(), check
mmap_count and return -EBUSY if the buffer is
currently mapped, preventing buffer replacement
while userspace holds stale PTEs. Tested with PoC
using dummy_hcd + raw_gadget USB device
emulation. |
| CVE-2026-43499 |
In the Linux kernel, the
following vulnerability has been resolved:
rtmutex: Use waiter::task instead of current in
remove_waiter() remove_waiter() is used by the
slowlock paths, but it is also used for proxy-lock
rollback in rt_mutex_start_proxy_lock() when
invoked from futex_requeue(). In the latter case
waiter::task is not current, but remove_waiter()
operates on current for the dequeue operation.
That results in several problems: 1) the rbtree
dequeue happens without waiter::task::pi_lock
being held 2) the waiter task's pi_blocked_on
state is not cleared, which leaves a dangling
pointer primed for UAF around. 3)
rt_mutex_adjust_prio_chain() operates on the wrong
top priority waiter task Use waiter::task instead
of current in all related operations in
remove_waiter() to cure those problems. [ tglx:
Fixup rt_mutex_adjust_prio_chain(), add a comment
and amend the changelog ] |
| CVE-2026-43500 |
In the Linux kernel, the
following vulnerability has been resolved: rxrpc:
Also unshare DATA/RESPONSE packets when paged
frags are present The DATA-packet handler in
rxrpc_input_call_event() and the RESPONSE handler
in rxrpc_verify_response() copy the skb to a
linear one before calling into the security ops
only when skb_cloned() is true. An skb that is not
cloned but still carries externally-owned paged
fragments (e.g. SKBFL_SHARED_FRAG set by splice()
into a UDP socket via __ip_append_data, or a
chained skb_has_frag_list()) falls through to the
in-place decryption path, which binds the frag
pages directly into the AEAD/skcipher SGL via
skb_to_sgvec(). Extend the gate to also unshare
when skb_has_frag_list() or skb_has_shared_frag()
is true. This catches the splice-loopback vector
and other externally-shared frag sources while
preserving the zero-copy fast path for skbs whose
frags are kernel-private (e.g. NIC page_pool RX,
GRO). The OOM/trace handling already in place is
reused. |
| CVE-2026-43501 |
In the Linux kernel, the
following vulnerability has been resolved: ipv6:
rpl: reserve mac_len headroom when recompressed
SRH grows ipv6_rpl_srh_rcv() decompresses an RFC
6554 Source Routing Header, swaps the next segment
into ipv6_hdr->daddr, recompresses, then pulls
the old header and pushes the new one plus the
IPv6 header back. The recompressed header can be
larger than the received one when the swap reduces
the common-prefix length the segments share with
daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0]
gives the maximum +8 bytes). pskb_expand_head()
was gated on segments_left == 0, so on earlier
segments the push consumed unchecked headroom.
Once skb_push() leaves fewer than skb->mac_len
bytes in front of data, skb_mac_header_rebuild()'s
call to: skb_set_mac_header(skb,
-skb->mac_len); will store (data - head) -
mac_len into the u16 mac_header field, which wraps
to ~65530, and the following memmove() writes
mac_len bytes ~64KiB past skb->head. A single
AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with
a two segment type-3 SRH (CmprI=0, CmprE=15)
reaches headroom 8 after one pass; KASAN reports a
14-byte OOB write in ipv6_rthdr_rcv. Fix this by
expanding the head whenever the remaining room is
less than the push size plus mac_len, and request
that much extra so the rebuilt MAC header fits
afterwards. |
| CVE-2026-43502 |
In the Linux kernel, the
following vulnerability has been resolved:
net/rds: handle zerocopy send cleanup before the
message is queued A zerocopy send can fail after
user pages have been pinned but before the message
is attached to the sending socket. The purge path
currently infers zerocopy state from rm->m_rs,
so an unqueued message can be cleaned up as if it
owned normal payload pages. However, zerocopy
ownership is really determined by the presence of
op_mmp_znotifier, regardless of whether the
message has reached the socket queue. Capture
op_mmp_znotifier up front in rds_message_purge()
and use it as the cleanup discriminator. If the
message is already associated with a socket, keep
the existing completion path. Otherwise, drop the
pinned page accounting directly and release the
notifier before putting the payload pages. This
keeps early send failure cleanup consistent with
the zerocopy lifetime rules without changing the
normal queued completion path. |
| CVE-2026-43503 |
In the Linux kernel, the
following vulnerability has been resolved: net:
skbuff: propagate shared-frag marker through
frag-transfer helpers Two frag-transfer helpers
(__pskb_copy_fclone() and skb_shift()) fail to
propagate the SKBFL_SHARED_FRAG bit in
skb_shinfo()->flags when moving frags from
source to destination. __pskb_copy_fclone() defers
the rest of the shinfo metadata to
skb_copy_header() after copying frag descriptors,
but that helper only carries over gso_{size,segs,
type} and never touches skb_shinfo()->flags;
skb_shift() moves frag descriptors directly and
leaves flags untouched. As a result, the
destination skb keeps a reference to the same
externally-owned or page-cache-backed pages while
reporting skb_has_shared_frag() as false. The
mismatch is harmful in any in-place writer that
uses skb_has_shared_frag() to decide whether
shared pages must be detoured through
skb_cow_data(). ESP input is one such writer
(esp4.c, esp6.c), and a single nft 'dup to
<local>' rule -- or any other nf_dup_ipv4()
/ xt_TEE caller -- is enough to land a
pskb_copy()'d skb in esp_input() with the marker
stripped, letting an unprivileged user write into
the page cache of a root-owned read-only file via
authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG
on the destination whenever frag descriptors were
actually moved from the source. skb_copy() and
skb_copy_expand() share skb_copy_header() too but
linearize all paged data into freshly allocated
head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own;
they need no change. The same omission exists in
skb_gro_receive() and skb_gro_receive_list(). The
former moves the incoming skb's frag descriptors
into the accumulator's last sub-skb via two paths
(a direct frag-move loop and the head_frag +
memcpy path); the latter chains the incoming skb
whole onto p's frag_list. Downstream skb_segment()
reads only skb_shinfo(p)->flags, and
skb_segment_list() reuses each sub-skb's shinfo as
the nskb -- both p and lp must carry the marker.
The same omission also exists in
tcp_clone_payload(), which builds an MTU probe skb
by moving frag descriptors from skbs on
sk_write_queue into a freshly allocated nskb. The
helper falls into the same family and warrants the
same fix for consistency; no TCP TX-side in-place
writer is currently known to reach a user page
through this gap, but a future consumer depending
on the marker would regress silently. The same
omission exists in skb_segment(): the
per-iteration flag merge takes only head_skb's
flag, and the inner switch that rebinds frag_skb
to list_skb on head_skb-frags exhaustion does not
fold the new frag_skb's flag into nskb. Fold
frag_skb's flag at both sites so segments drawing
frags from frag_list members carry the
marker. |
| CVE-2026-44016 |
### Impact In versions `>=
2.82.0, < 2.91.0`, if the HTML backend was
explicitly configured for rendering (rendering
option by default deactivated), then the
Playwright-based rendering feature could allow
JavaScript execution and unrestricted network
access when processing untrusted HTML documents.
An attacker could craft malicious HTML that
executes arbitrary JavaScript in the rendering
context or makes unauthorized network requests to
internal services, potentially leading to SSRF
attacks, data exfiltration, or remote code
execution in the rendering environment. ###
Patches Fixed in version 2.91.0. The rendering
context now explicitly disables JavaScript
execution (`java_script_enabled=False`) and
implements network isolation controls. When
`enable_remote_fetch` is disabled, the browser
operates in offline mode, preventing all network
requests. ### Workarounds Refrain from using
`render_page=True` when processing untrusted HTML
documents. ### References - Fix release:
[v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0) |
| CVE-2026-44017 |
### Impact In versions `<
2.91.0`, The EasyOCR model download functionality
extracted ZIP archives without validating member
paths, enabling Zip Slip attacks. If an attacker
could compromise the model download source (via
supply chain attack, DNS spoofing, or MITM), they
could write arbitrary files to any location
writable by the process, potentially achieving: -
Remote code execution by overwriting Python files
or system binaries - Persistent backdoors by
modifying startup scripts or SSH keys - Data
corruption or system compromise ### Patches Fixed
in version 2.91.0. The extraction process now
validates each archive member path using
`os.path.realpath()` to ensure it remains within
the target directory, raising a `SecurityError`
for any path traversal attempts. ### Workarounds
Ensure model downloads occur over secure,
authenticated channels. Use integrity verification
(checksums) for downloaded models. Run the
application with minimal file system permissions.
### References - Fix release:
[v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0) |
| CVE-2026-44018 |
### Impact The METS-GBS
backend's XML parsing and the input document
format detection lacked security controls,
enabling: - XML External Entity (XXE) attacks to
read local files or cause denial of service -
Decompression bombs (zip bombs) to exhaust memory
and disk space - Unbounded archive extraction
consuming system resources An attacker could craft
malicious METS-GBS archives that, when processed,
could read sensitive files, exhaust system
resources, or cause application crashes. ###
Patches Fixed in version 2.91.0. The fix
implements: - Secure XML parsing with
`resolve_entities=False`, `load_dtd=False`, and
`no_network=True` - Configurable limits: 300 MB
total extraction size, 10 MB per file, 1000 member
count - Cumulative size tracking across all
extractions - Early termination when limits are
exceeded - Secure format detection of METS-GBS tar
archives with `_detect_mets_gbs()` method: maximum
file size (10 MB per file), maximum member count
(1000 members), and exception handling to
gracefully fail when limits are exceeded ###
Workarounds Avoid processing METS-GBS archives
from untrusted sources. If necessary, pre-validate
archives in an isolated environment with resource
limits. ### References - Fix release:
[v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0) |
| CVE-2026-44019 |
### Impact In versions `>=
2.5.0, < 2.74.1`, `docling-core` could allow
local `file://` image references and accepted
inline `data:` content without a decoded-size
limit. In applications that accept untrusted image
references, this may allow access to local files
readable by the process or excessive memory use
from large inline payloads. ### Patches Patched in
`docling-core` `2.74.1`. The fix blocks local file
URIs by default and adds a size limit for decoded
inline image data. Users should upgrade to: -
`docling-core` `>= 2.74.1` ### Workarounds If
upgrading is not immediately possible: - reject
`file:` and `data:` image references from
untrusted input - allow only approved local or
remote image sources - apply input size and memory
limits to processing workers ### References - Fix
release:
[`v2.74.1`](https://github.com/docling-project/docling-core/releases/tag/v2.74.1) |
| CVE-2026-44022 |
### Impact The LaTeX backend's
handling of `\includegraphics`, `\input`, and
`\include` commands lacked path containment
validation. Attackers could craft malicious LaTeX
documents with path traversal sequences (e.g.,
`../../../etc/passwd`) to: - Read arbitrary files
from the file system accessible to the process -
Include sensitive files in the converted document
output - Potentially access configuration files,
credentials, or other sensitive data ### Patches
Fixed in version 2.91.0. The fix implements strict
path validation using
`Path.resolve().is_relative_to()` to ensure all
resolved paths remain within the base document
directory. Attempts to traverse outside the base
directory are logged and blocked. ### Workarounds
Avoid processing untrusted LaTeX documents. If
processing is necessary, run in a sandboxed
environment with restricted file system access.
### References - Fix release:
[v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0) |
| CVE-2026-44023 |
### Impact In versions `>=
1.5.0, < 2.74.1`, `docling-core` did not
sufficiently restrict remote request destinations
and could resolve a server-provided
`Content-Disposition` to a local path in an unsafe
manner. In applications that accept untrusted
URLs, this could allow SSRF attacks targeting
local files outside the user-defined cache
directory. ### Patches Patched in `docling-core`
`2.74.1`. The fix adds stricter validation for
remote destinations and normalizes server-provided
filenames before use. Users should upgrade to: -
`docling-core` `>= 2.74.1` ### Workarounds If
upgrading is not immediately possible, avoid
passing untrusted URLs into remote fetch
functionality. ### References - Fix release:
[`v2.74.1`](https://github.com/docling-project/docling-core/releases/tag/v2.74.1) |
| CVE-2026-44209 |
Banks generates meaningful LLM
prompts using a template language that makes
sense. Prior to 2.4.2, banks uses
jinja2.Environment() (unsandboxed) to render
prompt templates. Applications that pass
user-supplied strings as the template argument to
Prompt() are vulnerable to Server-Side Template
Injection (SSTI), which can lead to Remote Code
Execution (RCE) on the host system. This
vulnerability is fixed in 2.4.2. |
| CVE-2026-44489 |
Axios is a promise based HTTP
client for the browser and Node.js. From 1.15.2 to
before 1.16.0, nested objects created by
utils.merge() (e.g., config.proxy) are still
constructed as plain {} with Object.prototype in
their chain. The setProxy() function at
lib/adapters/http.js:209-223 reads proxy.username,
proxy.password, and proxy.auth without
hasOwnProperty checks. When
Object.prototype.username is polluted, setProxy()
constructs a Proxy-Authorization header with
attacker-controlled credentials and injects it
into every proxied HTTP request. This
vulnerability is fixed in 1.16.0. |
| CVE-2026-44843 |
LangChain is a framework for
building agents and LLM-powered applications.
Prior to 0.3.85 and 1.3.3, LangChain contains
older runtime code paths that deserialize run
inputs, run outputs, or other
application-controlled payloads using overly broad
object allowlists. These paths may call load()
with allowed_objects="all". This does not enable
arbitrary Python object deserialization, but it
does allow any trusted LangChain-serializable
object to be revived, which is broader than these
runtime paths require. As a result,
attacker-supplied LangChain serialized constructor
dictionaries may cause trusted runtime paths to
instantiate classes with untrusted constructor
arguments. This vulnerability is fixed in 0.3.85
and 1.3.3. |
| CVE-2026-44898 |
Mistune is a Python Markdown
parser with renderers and plugins. Prior to 3.2.1,
render_toc_ul() builds a <ul>
table-of-contents tree from a list of (level, id,
text) tuples. Both the id value (used as
href="#<id>") and the text value (used as
the visible link label) are inserted into
<a> tags via a plain Python format string —
with no HTML escaping applied to either value.
When heading IDs are derived from user-supplied
heading text (the standard use-case for readable
slug anchors), an attacker can craft a heading
whose text breaks out of the href="#..." attribute
context, injecting arbitrary HTML tags including
<script> blocks directly into the rendered
TOC. This vulnerability is fixed in 3.2.1. |
| CVE-2026-44899 |
Mistune is a Python Markdown
parser with renderers and plugins. Prior to 3.2.1,
the Image directive plugin validates the :width:
and :height: options with a regex compiled as
_num_re = re.compile(r"^\d+(?:\.\d*)?"). When the
validated value is not a plain integer,
render_block_image() inserts it directly into a
style="width:...;" or style="height:...;"
attribute. Because the value was accepted by the
prefix-only regex, any CSS after the leading
digits reaches the style= attribute verbatim and
without escaping. This vulnerability is fixed in
3.2.1. |
| CVE-2026-45149 |
The brace-expansion library
generates arbitrary strings containing a common
prefix and suffix. From 5.0.0 to before 5.0.6, the
max option was being applied too late. When
expanding a single large numeric range like
{1..10000000}, the sequence generation loop
generates all 10 million intermediate elements
before the max limit is applied With max=10, the
output is correctly limited to 10 items, but the
process still allocates ~505 MB and spends ~800ms
building the full intermediate array. This
vulnerability is fixed in 5.0.6. |
| CVE-2026-45834 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: L2CAP: Fix null-ptr-deref in
l2cap_sock_state_change_cb() Add the same NULL
guard already present in l2cap_sock_resume_cb()
and l2cap_sock_ready_cb(). |
| CVE-2026-45835 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: L2CAP: Fix null-ptr-deref in
l2cap_sock_new_connection_cb() Add the same NULL
guard already present in l2cap_sock_resume_cb()
and l2cap_sock_ready_cb(). |
| CVE-2026-45836 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: L2CAP: Fix null-ptr-deref in
l2cap_sock_get_sndtimeo_cb() Add the same NULL
guard already present in l2cap_sock_resume_cb()
and l2cap_sock_ready_cb(). |
| CVE-2026-45838 |
In the Linux kernel, the
following vulnerability has been resolved: bpf:
fix end-of-list detection in
cgroup_storage_get_next_key() list_next_entry()
never returns NULL -- when the current element is
the last entry it wraps to the list head via
container_of(). The subsequent NULL check is
therefore dead code and get_next_key() never
returns -ENOENT for the last element, instead
reading storage->key from a bogus pointer that
aliases internal map fields and copying the result
to userspace. Replace it with list_entry_is_head()
so the function correctly returns -ENOENT when
there are no more entries. |
| CVE-2026-45839 |
In the Linux kernel, the
following vulnerability has been resolved: bpf:
reject negative CO-RE accessor indices in
bpf_core_parse_spec() CO-RE accessor strings are
colon-separated indices that describe a path from
a root BTF type to a target field, e.g. "0:1:2"
walks through nested struct members.
bpf_core_parse_spec() parses each component with
sscanf("%d"), so negative values like -1 are
silently accepted. The subsequent bounds checks
(access_idx >= btf_vlen(t)) only guard the
upper bound and always pass for negative values
because C integer promotion converts the __u16
btf_vlen result to int, making the comparison
(int)(-1) >= (int)(N) false for any positive N.
When -1 reaches btf_member_bit_offset() it gets
cast to u32 0xffffffff, producing an out-of-bounds
read far past the members array. A crafted BPF
program with a negative CO-RE accessor on any
struct that exists in vmlinux BTF (e.g.
task_struct) crashes the kernel deterministically
during BPF_PROG_LOAD on any system with
CONFIG_DEBUG_INFO_BTF=y (default on major
distributions). The bug is reachable with CAP_BPF:
BUG: unable to handle page fault for address:
ffffed11818b6626 #PF: supervisor read access in
kernel mode #PF: error_code(0x0000) - not-present
page Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0
UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18
PREEMPT(full) RIP: 0010:bpf_core_parse_spec
(tools/lib/bpf/relo_core.c:354) RAX:
00000000ffffffff Call Trace: <TASK>
bpf_core_calc_relo_insn
(tools/lib/bpf/relo_core.c:1321) bpf_core_apply
(kernel/bpf/btf.c:9507) check_core_relo
(kernel/bpf/verifier.c:19475) bpf_check
(kernel/bpf/verifier.c:26031) bpf_prog_load
(kernel/bpf/syscall.c:3089) __sys_bpf
(kernel/bpf/syscall.c:6228) </TASK> CO-RE
accessor indices are inherently non-negative
(struct member index, array element index, or
enumerator index), so reject them immediately
after parsing. |
| CVE-2026-45840 |
In the Linux kernel, the
following vulnerability has been resolved:
openvswitch: cap upcall PID array size and
pre-size vport replies The vport netlink reply
helpers allocate a fixed-size skb with
nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize
the full upcall PID array via
ovs_vport_get_upcall_portids(). Since
ovs_vport_set_upcall_portids() accepts any
non-zero multiple of sizeof(u32) with no upper
bound, a CAP_NET_ADMIN user can install a PID
array large enough to overflow the reply buffer,
causing nla_put() to fail with -EMSGSIZE and
hitting BUG_ON(err < 0). On systems with
unprivileged user namespaces enabled (e.g., Ubuntu
default), this is reachable via unshare -Urn since
OVS vport mutation operations use
GENL_UNS_ADMIN_PERM. kernel BUG at
net/openvswitch/datapath.c:2414! Oops: invalid
opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0
PID: 65 Comm: poc Not tainted
7.0.0-rc7-00195-geb216e422044 #1 RIP:
0010:ovs_vport_cmd_set+0x34c/0x400 Call Trace:
<TASK> genl_family_rcv_msg_doit
(net/netlink/genetlink.c:1116) genl_rcv_msg
(net/netlink/genetlink.c:1194) netlink_rcv_skb
(net/netlink/af_netlink.c:2550) genl_rcv
(net/netlink/genetlink.c:1219) netlink_unicast
(net/netlink/af_netlink.c:1344) netlink_sendmsg
(net/netlink/af_netlink.c:1894) __sys_sendto
(net/socket.c:2206) __x64_sys_sendto
(net/socket.c:2209) do_syscall_64
(arch/x86/entry/syscall_64.c:63)
entry_SYSCALL_64_after_hwframe
(arch/x86/entry/entry_64.S:130) </TASK>
Kernel panic - not syncing: Fatal exception Reject
attempts to set more PIDs than nr_cpu_ids in
ovs_vport_set_upcall_portids(), and pre-compute
the worst-case reply size in
ovs_vport_cmd_msg_size() based on that bound,
similar to the existing ovs_dp_cmd_msg_size().
nr_cpu_ids matches the cap already used by the
per-CPU dispatch configuration on the datapath
side (ovs_dp_cmd_fill_info() serialises at most
nr_cpu_ids PIDs), so the two sides stay
consistent. |
| CVE-2026-45841 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nfnetlink_osf: fix divide-by-zero in
OSF_WSS_MODULO nf_osf_match_one() computes
ctx->window % f->wss.val in the
OSF_WSS_MODULO branch with no guard for
f->wss.val == 0. A CAP_NET_ADMIN user can add
such a fingerprint via nfnetlink; a subsequent
matching TCP SYN divides by zero and panics the
kernel. Reject the bogus fingerprint in
nfnl_osf_add_callback() above the per-option
for-loop. f->wss is per-fingerprint, not
per-option, so the check must run regardless of
f->opt_num (including 0). Also reject wss.wc
>= OSF_WSS_MAX; nf_osf_match_one() already
treats that as "should not happen". Crash: Oops:
divide error: 0000 [#1] SMP KASAN NOPTI RIP:
0010:nf_osf_match_one
(net/netfilter/nfnetlink_osf.c:98) Call Trace:
<IRQ> nf_osf_match
(net/netfilter/nfnetlink_osf.c:220)
xt_osf_match_packet (net/netfilter/xt_osf.c:32)
ipt_do_table (net/ipv4/netfilter/ip_tables.c:348)
nf_hook_slow (net/netfilter/core.c:622)
ip_local_deliver (net/ipv4/ip_input.c:265) ip_rcv
(include/linux/skbuff.h:1162)
__netif_receive_skb_one_core (net/core/dev.c:6181)
process_backlog (net/core/dev.c:6642) __napi_poll
(net/core/dev.c:7710) net_rx_action
(net/core/dev.c:7945) handle_softirqs
(kernel/softirq.c:622) |
| CVE-2026-45842 |
In the Linux kernel, the
following vulnerability has been resolved: slip:
reject VJ receive packets on instances with no
rstate array slhc_init() accepts rslots == 0 as a
valid configuration, with the documented meaning
of 'no receive compression'. In that case the
allocation loop in slhc_init() is skipped, so
comp->rstate stays NULL and
comp->rslot_limit stays 0 (from the kzalloc of
struct slcompress). The receive helpers do not
defend against that configuration.
slhc_uncompress() dereferences comp->rstate[x]
when the VJ header carries an explicit connection
ID, and slhc_remember() later assigns cs =
&comp->rstate[...] after only comparing the
packet's slot number to comp->rslot_limit.
Because rslot_limit is 0, slot 0 passes the range
check, and the code dereferences a NULL rstate.
The configuration is reachable in-tree through
PPP. PPPIOCSMAXCID stores its argument in a signed
int, and (val >> 16) uses arithmetic shift.
Passing 0xffff0000 therefore sign-extends to -1,
so val2 + 1 is 0 and ppp_generic.c ends up calling
slhc_init(0, 1). Because /dev/ppp open is gated by
ns_capable(CAP_NET_ADMIN), the whole path is
reachable from an unprivileged user namespace.
Once the malformed VJ state is installed, any
inbound VJ-compressed or VJ-uncompressed frame
that selects slot 0 crashes the kernel in softirq
context: Oops: general protection fault, probably
for non-canonical address 0xdffffc0000000000: 0000
[#1] SMP KASAN NOPTI KASAN: null-ptr-deref in
range [0x0000000000000000-0x0000000000000007] RIP:
0010:slhc_uncompress (drivers/net/slip/slhc.c:519)
Call Trace: <TASK> ppp_receive_nonmp_frame
(drivers/net/ppp/ppp_generic.c:2466) ppp_input
(drivers/net/ppp/ppp_generic.c:2359)
ppp_async_process
(drivers/net/ppp/ppp_async.c:492)
tasklet_action_common (kernel/softirq.c:926)
handle_softirqs (kernel/softirq.c:623)
run_ksoftirqd (kernel/softirq.c:1055)
smpboot_thread_fn (kernel/smpboot.c:160) kthread
(kernel/kthread.c:436) ret_from_fork
(arch/x86/kernel/process.c:164) </TASK>
Reject the receive side on such instances instead
of touching rstate. slhc_uncompress() falls
through to its existing 'bad' label, which bumps
sls_i_error and enters the toss state.
slhc_remember() mirrors that with an explicit
sls_i_error increment followed by slhc_toss(); the
sls_i_runt counter is not used here because a
missing rstate is an internal configuration state,
not a runt packet. The transmit path is
unaffected: the only in-tree caller that picks
rslots from userspace (ppp_generic.c) still
supplies tslots >= 1, and slip.c always calls
slhc_init(16, 16), so comp->tstate remains
valid and slhc_compress() continues to
work. |
| CVE-2026-45843 |
In the Linux kernel, the
following vulnerability has been resolved: slip:
bound decode() reads against the compressed packet
length slhc_uncompress() parses a VJ-compressed
TCP header by advancing a pointer through the
packet via decode() and pull16(). Neither helper
bounds-checks against isize, and decode() masks
its return with & 0xffff so it can never
return the -1 that callers test for -- those error
paths are dead code. A short compressed frame
whose change byte requests optional fields lets
decode() read past the end of the packet. The
over-read bytes are folded into the cached cstate
and reflected into subsequent reconstructed
packets. Make decode() and pull16() take the
packet end pointer and return -1 when exhausted.
Add a bounds check before the TCP-checksum read.
The existing == -1 tests now do what they were
always meant to. |
| CVE-2026-45844 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: arp_tables: fix IEEE1394 ARP payload
parsing Weiming Shi says: "arp_packet_match()
unconditionally parses the ARP payload assuming
two hardware addresses are present (source and
target). However, IPv4-over-IEEE1394 ARP (RFC
2734) omits the target hardware address field, and
arp_hdr_len() already accounts for this by
returning a shorter length for ARPHRD_IEEE1394
devices. As a result, on IEEE1394 interfaces
arp_packet_match() advances past a nonexistent
target hardware address and reads the wrong bytes
for both the target device address comparison and
the target IP address. This causes arptables rules
to match against garbage data, leading to
incorrect filtering decisions: packets that should
be accepted may be dropped and vice versa. The ARP
stack in net/ipv4/arp.c (arp_create and
arp_process) already handles this correctly by
skipping the target hardware address for
ARPHRD_IEEE1394. Apply the same pattern to
arp_packet_match()." Mangle the original patch to
always return 0 (no match) in case user matches on
the target hardware address which is never present
in IEEE1394. Note that this returns 0 (no match)
for either normal and inverse match because
matching in the target hardware address in
ARPHRD_IEEE1394 has never been supported by
arptables. This is intentional, matching on the
target hardware address should never evaluate true
for ARPHRD_IEEE1394. Moreover, adjust arpt_mangle
to drop the packet too as AI suggests: In
arpt_mangle, the logic assumes a standard ARP
layout. Because IEEE1394 (FireWire) omits the
target hardware address, the linear pointer
arithmetic miscalculates the offset for the target
IP address. This causes mangling operations to
write to the wrong location, leading to packet
corruption. To ensure safety, this patch drops
packets (NF_DROP) when mangling is requested for
these fields on IEEE1394 devices, as the current
implementation cannot correctly map the FireWire
ARP payload. This omits both mangling target
hardware and IP address. Even if IP address
mangling should be possible in IEEE1394, this
would require to adjust arpt_mangle offset
calculation, which has never been supported. Based
on patch from Weiming Shi
<bestswngs@gmail.com>. |
| CVE-2026-45845 |
In the Linux kernel, the
following vulnerability has been resolved:
net/sched: taprio: fix NULL pointer dereference in
class dump When a TAPRIO child qdisc is deleted
via RTM_DELQDISC, taprio_graft() is called with
new == NULL and stores NULL into q->qdiscs[cl -
1]. Subsequent RTM_GETTCLASS dump operations walk
all classes via taprio_walk() and call
taprio_dump_class(), which calls taprio_leaf()
returning the NULL pointer, then dereferences it
to read child->handle, causing a kernel NULL
pointer dereference. The bug is reachable with
namespace-scoped CAP_NET_ADMIN on any kernel with
CONFIG_NET_SCH_TAPRIO enabled. On systems with
unprivileged user namespaces enabled, an
unprivileged local user can trigger a kernel panic
by creating a taprio qdisc inside a new network
namespace, grafting an explicit child qdisc,
deleting it, and requesting a class dump. The
RTM_GETTCLASS dump itself requires no capability.
Oops: general protection fault, probably for
non-canonical address 0xdffffc0000000007: 0000
[#1] SMP KASAN NOPTI KASAN: null-ptr-deref in
range [0x0000000000000038-0x000000000000003f] RIP:
0010:taprio_dump_class
(net/sched/sch_taprio.c:2478) Call Trace:
<TASK> tc_fill_tclass
(net/sched/sch_api.c:1966) qdisc_class_dump
(net/sched/sch_api.c:2326) taprio_walk
(net/sched/sch_taprio.c:2514) tc_dump_tclass_qdisc
(net/sched/sch_api.c:2352) tc_dump_tclass_root
(net/sched/sch_api.c:2370) tc_dump_tclass
(net/sched/sch_api.c:2431) rtnl_dumpit
(net/core/rtnetlink.c:6864) netlink_dump
(net/netlink/af_netlink.c:2325) rtnetlink_rcv_msg
(net/core/rtnetlink.c:6959) netlink_rcv_skb
(net/netlink/af_netlink.c:2550) </TASK> Fix
this by substituting &noop_qdisc when new is
NULL in taprio_graft(), a common pattern used by
other qdiscs (e.g., multiq_graft()) to ensure the
q->qdiscs[] slots are never NULL. This makes
control-plane dump paths safe without requiring
individual NULL checks. Since the data-plane paths
(taprio_enqueue and taprio_dequeue_from_txq)
previously had explicit NULL guards that would
drop/skip the packet cleanly, update those checks
to test for &noop_qdisc instead. Without this,
packets would reach taprio_enqueue_one() which
increments the root qdisc's qlen and backlog
before calling the child's enqueue; noop_qdisc
drops the packet but those counters are never
rolled back, permanently inflating the root
qdisc's statistics. After this change *old can be
a valid qdisc, NULL, or &noop_qdisc. Only call
qdisc_put(*old) in the first case to avoid
decreasing noop_qdisc's refcount, which was never
increased. |
| CVE-2026-45846 |
In the Linux kernel, the
following vulnerability has been resolved:
bareudp: fix NULL pointer dereference in
bareudp_fill_metadata_dst()
bareudp_fill_metadata_dst() passes
bareudp->sock to udp_tunnel6_dst_lookup() in
the IPv6 path without a NULL check. The socket is
only created in bareudp_open() and NULLed in
bareudp_stop(), so calling this function while the
device is down triggers a NULL dereference via
sock->sk. BUG: kernel NULL pointer dereference,
address: 0000000000000018 RIP:
0010:udp_tunnel6_dst_lookup
(net/ipv6/ip6_udp_tunnel.c:160) Call Trace:
<TASK> bareudp_fill_metadata_dst
(drivers/net/bareudp.c:532) do_execute_actions
(net/openvswitch/actions.c:901)
ovs_execute_actions
(net/openvswitch/actions.c:1589)
ovs_packet_cmd_execute
(net/openvswitch/datapath.c:700)
genl_family_rcv_msg_doit
(net/netlink/genetlink.c:1114) genl_rcv_msg
(net/netlink/genetlink.c:1209) netlink_rcv_skb
(net/netlink/af_netlink.c:2550) </TASK> Add
a NULL check returning -ESHUTDOWN, consistent with
the xmit paths in the same driver. |
| CVE-2026-45850 |
In the Linux kernel, the
following vulnerability has been resolved: ipvs:
skip ipv6 extension headers for csum checks
Protocol checksum validation fails for IPv6 if
there are extension headers before the protocol
header. iph->len already contains its offset,
so use it to fix the problem. |
| CVE-2026-45894 |
In the Linux kernel, the
following vulnerability has been resolved:
iommu/vt-d: Clear Present bit before tearing down
PASID entry The Intel VT-d Scalable Mode PASID
table entry consists of 512 bits (64 bytes). When
tearing down an entry, the current implementation
zeros the entire 64-byte structure immediately
using multiple 64-bit writes. Since the IOMMU
hardware may fetch these 64 bytes using multiple
internal transactions (e.g., four 128-bit bursts),
updating or zeroing the entire entry while it is
active (P=1) risks a "torn" read. If a hardware
fetch occurs simultaneously with the CPU zeroing
the entry, the hardware could observe an
inconsistent state, leading to unpredictable
behavior or spurious faults. Follow the "Guidance
to Software for Invalidations" in the VT-d spec
(Section 6.5.3.3) by implementing the recommended
ownership handshake: 1. Clear only the 'Present'
(P) bit of the PASID entry. 2. Use a dma_wmb() to
ensure the cleared bit is visible to hardware
before proceeding. 3. Execute the required
invalidation sequence (PASID cache, IOTLB, and
Device-TLB flush) to ensure the hardware has
released all cached references. 4. Only after the
flushes are complete, zero out the remaining
fields of the PASID entry. Also, add a dma_wmb()
in pasid_set_present() to ensure that all other
fields of the PASID entry are visible to the
hardware before the Present bit is set. |
| CVE-2026-45897 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nft_counter: serialize reset with
spinlock Add a global static spinlock to serialize
counter fetch+reset operations, preventing
concurrent dump-and-reset from underrunning
values. The lock is taken before fetching the
total so that two parallel resets cannot both read
the same counter values and then both subtract
them. A global lock is used for simplicity since
resets are infrequent. If this becomes a
bottleneck, it can be replaced with a per-net lock
later. |
| CVE-2026-45901 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nf_tables: revert commit_mutex usage in
reset path It causes circular lock dependency
between commit_mutex, nfnl_subsys_ipset and
nlk_cb_mutex when nft reset, ipset list, and
iptables-nft with '-m set' rule run at the same
time. Previous patches made it safe to run
individual reset handlers concurrently so
commit_mutex is no longer required to prevent
this. |
| CVE-2026-45930 |
In the Linux kernel, the
following vulnerability has been resolved: net:
mctp: ensure our nlmsg responses are initialised
Syed Faraz Abrar (@farazsth98) from Zellic, and
Pumpkin (@u1f383) from DEVCORE Research Team
working with Trend Micro Zero Day Initiative
report that a RTM_GETNEIGH will return
uninitalised data in the pad bytes of the ndmsg
data. Ensure we're initialising the netlink data
to zero, in the link, addr and neigh response
messages. |
| CVE-2026-45932 |
In the Linux kernel, the
following vulnerability has been resolved: bpf:
Fix tcx/netkit detach permissions when prog fd
isn't given This commit fixes a security issue
where BPF_PROG_DETACH on tcx or netkit devices
could be executed by any user when no program fd
was provided, bypassing permission checks. The fix
adds a capability check for CAP_NET_ADMIN or
CAP_SYS_ADMIN in this case. |
| CVE-2026-45934 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
fix EEXIST abort due to non-consecutive gaps in
chunk allocation I have been observing a number of
systems aborting at insert_dev_extents() in
btrfs_create_pending_block_groups(). The following
is a sample stack trace of such an abort coming
from forced chunk allocation (typically behind
CONFIG_BTRFS_EXPERIMENTAL) but this can
theoretically happen to any DUP chunk allocation.
[81.801] ------------[ cut here ]------------
[81.801] BTRFS: Transaction aborted (error -17)
[81.801] WARNING: fs/btrfs/block-group.c:2876 at
btrfs_create_pending_block_groups+0x721/0x770
[btrfs], CPU#1: bash/319 [81.802] Modules linked
in: virtio_net btrfs xor zstd_compress raid6_pq
null_blk [81.803] CPU: 1 UID: 0 PID: 319 Comm:
bash Kdump: loaded Not tainted 6.19.0-rc6+ #319
NONE [81.803] Hardware name: QEMU Standard PC
(i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2
04/01/2014 [81.804] RIP:
0010:btrfs_create_pending_block_groups+0x723/0x770
[btrfs] [81.806] RSP: 0018:ffffa36241a6bce8
EFLAGS: 00010282 [81.806] RAX: 000000000000000d
RBX: ffff8e699921e400 RCX: 0000000000000000
[81.807] RDX: 0000000002040001 RSI:
00000000ffffffef RDI: ffffffffc0608bf0 [81.807]
RBP: 00000000ffffffef R08: ffff8e69830f6000 R09:
0000000000000007 [81.808] R10: ffff8e699921e5e8
R11: 0000000000000000 R12: ffff8e6999228000
[81.808] R13: ffff8e6984d82000 R14:
ffff8e69966a69c0 R15: ffff8e69aa47b000 [81.809]
FS: 00007fec6bdd9740(0000)
GS:ffff8e6b1b379000(0000) knlGS:0000000000000000
[81.809] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033 [81.810] CR2: 00005604833670f0
CR3: 0000000116679000 CR4: 00000000000006f0
[81.810] Call Trace: [81.810] <TASK>
[81.810] __btrfs_end_transaction+0x3e/0x2b0
[btrfs] [81.811]
btrfs_force_chunk_alloc_store+0xcd/0x140 [btrfs]
[81.811] kernfs_fop_write_iter+0x15f/0x240
[81.812] vfs_write+0x264/0x500 [81.812]
ksys_write+0x6c/0xe0 [81.812]
do_syscall_64+0x66/0x770 [81.812]
entry_SYSCALL_64_after_hwframe+0x76/0x7e [81.813]
RIP: 0033:0x7fec6be66197 [81.814] RSP:
002b:00007fffb159dd30 EFLAGS: 00000202 ORIG_RAX:
0000000000000001 [81.815] RAX: ffffffffffffffda
RBX: 00007fec6bdd9740 RCX: 00007fec6be66197
[81.815] RDX: 0000000000000002 RSI:
0000560483374f80 RDI: 0000000000000001 [81.816]
RBP: 0000560483374f80 R08: 0000000000000000 R09:
0000000000000000 [81.816] R10: 0000000000000000
R11: 0000000000000202 R12: 0000000000000002
[81.817] R13: 00007fec6bfb85c0 R14:
00007fec6bfb5ee0 R15: 00005604833729c0 [81.817]
</TASK> [81.817] irq event stamp: 20039
[81.818] hardirqs last enabled at (20047):
[<ffffffff99a68302>]
__up_console_sem+0x52/0x60 [81.818] hardirqs last
disabled at (20056): [<ffffffff99a682e7>]
__up_console_sem+0x37/0x60 [81.819] softirqs last
enabled at (19470): [<ffffffff999d2b46>]
__irq_exit_rcu+0x96/0xc0 [81.819] softirqs last
disabled at (19463): [<ffffffff999d2b46>]
__irq_exit_rcu+0x96/0xc0 [81.820] ---[ end trace
0000000000000000 ]--- [81.820] BTRFS: error
(device dm-7 state A) in
btrfs_create_pending_block_groups:2876: errno=-17
Object already exists Inspecting these aborts with
drgn, I observed a pattern of overlapping
chunk_maps. Note how stripe 1 of the first chunk
overlaps in physical address with stripe 0 of the
second chunk. Physical Start Physical End Length
Logical Type Stripe
----------------------------------------------------------------------------------------------------
0x0000000102500000 0x0000000142500000 1.0G
0x0000000641d00000 META|DUP 0/2 0x0000000142500000
0x0000000182500000 1.0G 0x0000000641d00000
META|DUP 1/2 0x0000000142500000 0x0000000182500000
1.0G 0x0000000601d00000 META|DUP 0/2
0x0000000182500000 0x00000001c2500000 1.0G
0x0000000601d00000 META|DUP 1/2 Now how could this
possibly happen? All chunk allocation is
---truncated--- |
| CVE-2026-45940 |
In the Linux kernel, the
following vulnerability has been resolved: net:
stmmac: fix oops when split header is enabled For
GMAC4, when split header is enabled, in some rare
cases, the hardware does not fill buf2 of the
first descriptor with payload. Thus we cannot
assume buf2 is always fully filled if it is not
the last descriptor. Otherwise, the length of buf2
of the second descriptor will be calculated wrong
and cause an oops: Unable to handle kernel paging
request at virtual address ffff00019246bfc0 ... x2
: 0000000000000040 x1 : ffff00019246bfc0 x0 :
ffff00009246c000 Call trace:
dcache_inval_poc+0x28/0x58 (P)
dma_direct_sync_single_for_cpu+0x38/0x6c
__dma_sync_single_for_cpu+0x34/0x6c
stmmac_napi_poll_rx+0x8f0/0xb60
__napi_poll.constprop.0+0x30/0x144
net_rx_action+0x160/0x274
handle_softirqs+0x1b8/0x1fc ... To fix this, the
PL bit-field in RDES3 register is used for all
descriptors, whether it is the last descriptor or
not. |
| CVE-2026-45944 |
In the Linux kernel, the
following vulnerability has been resolved:
iommu/vt-d: Clear Present bit before tearing down
context entry When tearing down a context entry,
the current implementation zeros the entire
128-bit entry using multiple 64-bit writes. This
creates a window where the hardware can fetch a
"torn" entry — where some fields are already
zeroed while the 'Present' bit is still set —
leading to unpredictable behavior or spurious
faults. While x86 provides strong write ordering,
the compiler may reorder writes to the two 64-bit
halves of the context entry. Even without compiler
reordering, the hardware fetch is not guaranteed
to be atomic with respect to multiple CPU writes.
Align with the "Guidance to Software for
Invalidations" in the VT-d spec (Section 6.5.3.3)
by implementing the recommended ownership
handshake: 1. Clear only the 'Present' (P) bit of
the context entry first to signal the transition
of ownership from hardware to software. 2. Use
dma_wmb() to ensure the cleared bit is visible to
the IOMMU. 3. Perform the required cache and
context-cache invalidation to ensure hardware no
longer has cached references to the entry. 4.
Fully zero out the entry only after the
invalidation is complete. Also, add a dma_wmb() to
context_set_present() to ensure the entry is fully
initialized before the 'Present' bit becomes
visible. |
| CVE-2026-45949 |
In the Linux kernel, the
following vulnerability has been resolved: hwrng:
core - use RCU and work_struct to fix race
condition Currently, hwrng_fill is not cleared
until the hwrng_fillfn() thread exits. Since
hwrng_unregister() reads hwrng_fill outside the
rng_mutex lock, a concurrent hwrng_unregister()
may call kthread_stop() again on the same task.
Additionally, if hwrng_unregister() is called
immediately after hwrng_register(), the stopped
thread may have never been executed. Thus,
hwrng_fill remains dirty even after
hwrng_unregister() returns. In this case,
subsequent calls to hwrng_register() will fail to
start new threads, and hwrng_unregister() will
call kthread_stop() on the same freed task. In
both cases, a use-after-free occurs: refcount_t:
addition on 0; use-after-free. WARNING: ... at
lib/refcount.c:25
refcount_warn_saturate+0xec/0x1c0 Call Trace:
kthread_stop+0x181/0x360
hwrng_unregister+0x288/0x380
virtrng_remove+0xe3/0x200 This patch fixes the
race by protecting the global hwrng_fill pointer
inside the rng_mutex lock, so that hwrng_fillfn()
thread is stopped only once, and calls to
kthread_run() and kthread_stop() are serialized
with the lock held. To avoid deadlock in
hwrng_fillfn() while being stopped with the lock
held, we convert current_rng to RCU, so that
get_current_rng() can read current_rng without
holding the lock. To remove the lock from
put_rng(), we also delay the actual cleanup into a
work_struct. Since get_current_rng() no longer
returns ERR_PTR values, the IS_ERR() checks are
removed from its callers. With hwrng_fill
protected by the rng_mutex lock, hwrng_fillfn()
can no longer clear hwrng_fill itself. Therefore,
if hwrng_fillfn() returns directly after
current_rng is dropped, kthread_stop() would be
called on a freed task_struct later. To fix this,
hwrng_fillfn() calls schedule() now to keep the
task alive until being stopped. The kthread_stop()
call is also moved from hwrng_unregister() to
drop_current_rng(), ensuring kthread_stop() is
called on all possible paths where current_rng
becomes NULL, so that the thread would not wait
forever. |
| CVE-2026-45961 |
In the Linux kernel, the
following vulnerability has been resolved: gfs2:
fix memory leaks in gfs2_fill_super error path Fix
two memory leaks in the gfs2_fill_super() error
handling path when transitioning a filesystem to
read-write mode fails. First leak: kthread objects
(thread_struct, task_struct, etc.) When
gfs2_freeze_lock_shared() fails after
init_threads() succeeds, the created kernel
threads (logd and quotad) are never destroyed.
This occurs because the fail_per_node label
doesn't call gfs2_destroy_threads(). Second leak:
quota bitmap buffer (8192 bytes) When
gfs2_make_fs_rw() fails after gfs2_quota_init()
succeeds but before other operations complete, the
allocated quota bitmap is never freed. The fix
moves thread cleanup to the fail_per_node label to
handle all error paths uniformly.
gfs2_destroy_threads() is safe to call
unconditionally as it checks for NULL pointers.
Quota cleanup is added in gfs2_make_fs_rw() to
properly handle the withdrawal case where quota
initialization succeeds but the filesystem is then
withdrawn. Thread leak backtrace
(gfs2_freeze_lock_shared failure): unreferenced
object 0xffff88801d7bca80 (size 4480):
copy_process+0x3a1/0x4670 kernel/fork.c:2422
kernel_clone+0xf3/0x6e0 kernel/fork.c:2779
kthread_create_on_node+0x100/0x150
kernel/kthread.c:478 init_threads+0xab/0x350
fs/gfs2/ops_fstype.c:611
gfs2_fill_super+0xe5c/0x1240
fs/gfs2/ops_fstype.c:1265 Quota leak backtrace
(gfs2_make_fs_rw failure): unreferenced object
0xffff88812de7c000 (size 8192):
gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409
gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149
gfs2_fill_super+0xfbb/0x1240
fs/gfs2/ops_fstype.c:1275 |
| CVE-2026-45963 |
In the Linux kernel, the
following vulnerability has been resolved: ASoC:
nau8821: Cancel delayed work on component remove
Attempting to unload the driver while a jack
detection work is pending would likely crash the
kernel when it is eventually scheduled for
execution: [ 1984.896308] BUG: unable to handle
page fault for address: ffffffffc10c2a20 [...] [
1984.896388] Hardware name: Valve Jupiter/Jupiter,
BIOS F7A0131 01/30/2024 [ 1984.896396] Workqueue:
events nau8821_jdet_work [snd_soc_nau8821] [
1984.896414] RIP: 0010:__mutex_lock+0x9f/0x11d0
[...] [ 1984.896504] Call Trace: [ 1984.896511]
<TASK> [ 1984.896524] ?
snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core]
[ 1984.896572] ?
snd_soc_dapm_disable_pin+0x26/0x60 [snd_soc_core]
[ 1984.896596] snd_soc_dapm_disable_pin+0x26/0x60
[snd_soc_core] [ 1984.896622]
nau8821_jdet_work+0xeb/0x1e0 [snd_soc_nau8821] [
1984.896636] process_one_work+0x211/0x590 [
1984.896649] ? srso_return_thunk+0x5/0x5f [
1984.896670] worker_thread+0x1cd/0x3a0 Cancel
unscheduled jdet_work or wait for its execution to
finish before the component driver gets
removed. |
| CVE-2026-45986 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
ccree - fix a memory leak in cc_mac_digest() Add
cc_unmap_result() if cc_map_hash_request_final()
fails to prevent potential memory leak. |
| CVE-2026-45987 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
nSVM: Sync interrupt shadow to cached vmcb12 after
VMRUN of L2 After VMRUN in guest mode,
nested_sync_control_from_vmcb02() syncs fields
written by the CPU from vmcb02 to the cached
vmcb12. This is because the cached vmcb12 is used
as the authoritative copy of some of the controls,
and is the payload when saving/restoring nested
state. int_state is also written by the CPU,
specifically bit 0 (i.e.
SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it
is not sync'd to cached vmcb12. This does not
cause a problem if KVM_SET_NESTED_STATE preceeds
KVM_SET_VCPU_EVENTS in the restore path, as an
interrupt shadow would be correctly restored to
vmcb02 (KVM_SET_VCPU_EVENTS overwrites what
KVM_SET_NESTED_STATE restored in int_state).
However, if KVM_SET_VCPU_EVENTS preceeds
KVM_SET_NESTED_STATE, an interrupt shadow would be
restored into vmcb01 instead of vmcb02. This would
mostly be benign for L1 (delays an interrupt), but
not for L2. For L2, the vCPU could hang (e.g. if a
wakeup interrupt is delivered before a HLT that
should have been in an interrupt shadow). Sync
int_state to the cached vmcb12 in
nested_sync_control_from_vmcb02() to avoid this
problem. With that, KVM_SET_NESTED_STATE restores
the correct interrupt shadow state, and if
KVM_SET_VCPU_EVENTS follows it would overwrite it
with the same value. |
| CVE-2026-45988 |
In the Linux kernel, the
following vulnerability has been resolved: rxrpc:
Fix re-decryption of RESPONSE packets If a
RESPONSE packet gets a temporary failure during
processing, it may end up in a partially decrypted
state - and then get requeued for a retry. Fix
this by just discarding the packet; we will send
another CHALLENGE packet and thereby elicit a
further response. Similarly, discard an incoming
CHALLENGE packet if we get an error whilst
generating a RESPONSE; the server will send
another CHALLENGE. |
| CVE-2026-45989 |
In the Linux kernel, the
following vulnerability has been resolved: of:
unittest: fix use-after-free in testdrv_probe()
The function testdrv_probe() retrieves the
device_node from the PCI device, applies an
overlay, and then immediately calls
of_node_put(dn). This releases the reference held
by the PCI core, potentially freeing the node if
the reference count drops to zero. Later, the same
freed pointer 'dn' is passed to
of_platform_default_populate(), leading to a
use-after-free. The reference to
pdev->dev.of_node is owned by the device model
and should not be released by the driver. Remove
the erroneous of_node_put() to prevent premature
freeing. |
| CVE-2026-45991 |
In the Linux kernel, the
following vulnerability has been resolved: udf:
fix partition descriptor append bookkeeping
Mounting a crafted UDF image with repeated
partition descriptors can trigger a heap
out-of-bounds write in part_descs_loc[].
handle_partition_descriptor() deduplicates entries
by partition number, but appended slots never
record partnum. As a result duplicate Partition
Descriptors are appended repeatedly and
num_part_descs keeps growing. Once the table is
full, the growth path still sizes the allocation
from partnum even though inserts are indexed by
num_part_descs. If partnum is already aligned to
PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can
keep the old capacity and the next append writes
past the end of the table. Store partnum in the
appended slot and size growth from the next append
count so deduplication and capacity tracking
follow the same model. |
| CVE-2026-45993 |
In the Linux kernel, the
following vulnerability has been resolved:
LoongArch: Add spectre boundry for syscall
dispatch table The LoongArch syscall number is
directly controlled by userspace, but does not
have a array_index_nospec() boundry to prevent
access past the syscall function pointer
tables. |
| CVE-2026-45994 |
In the Linux kernel, the
following vulnerability has been resolved: ibmasm:
fix OOB reads in command_file_write due to missing
size checks The command_file_write() handler
allocates a kernel buffer of exactly count bytes
and copies user data into it, but does not
validate the buffer against the dot command
protocol before passing it to
get_dot_command_size() and
get_dot_command_timeout(). Since both the
allocation size (count) and the header fields
(command_size, data_size) are independently
user-controlled, an attacker can cause
get_dot_command_size() to return a value exceeding
the allocation, triggering OOB reads in
get_dot_command_timeout() and an out-of-bounds
memcpy_toio() that leaks kernel heap memory to the
service processor. Fix with two guards: reject
writes smaller than sizeof(struct
dot_command_header) before allocation, then after
copying user data reject commands where the buffer
is smaller than the total size declared by the
header (sizeof(header) + command_size +
data_size). This ensures all subsequent header and
payload field accesses stay within the
buffer. |
| CVE-2026-45996 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
imx: fix use-after-free on unbind The SPI
subsystem frees the controller and any subsystem
allocated driver data as part of deregistration
(unless the allocation is device managed). Take
another reference before deregistering the
controller so that the driver data is not freed
until the driver is done with it. |
| CVE-2026-45997 |
In the Linux kernel, the
following vulnerability has been resolved: scsi:
sd: fix missing put_disk() when
device_add(&disk_dev) fails If
device_add(&sdkp->disk_dev) fails,
put_device() runs scsi_disk_release(), which frees
the scsi_disk but leaves the gendisk referenced.
The device_add_disk() error path in sd_probe()
calls put_disk(gd); call put_disk(gd) here to
mirror that cleanup. |
| CVE-2026-45998 |
In the Linux kernel, the
following vulnerability has been resolved: rxrpc:
Fix potential UAF after skb_unshare() failure If
skb_unshare() fails to unshare a packet due to
allocation failure in rxrpc_input_packet(), the
skb pointer in the parent (rxrpc_io_thread()) will
be NULL'd out. This will likely cause the call to
trace_rxrpc_rx_done() to oops. Fix this by moving
the unsharing down to where
rxrpc_input_call_event() calls
rxrpc_input_call_packet(). There are a number of
places prior to that where we ignore DATA packets
for a variety of reasons (such as the call already
being complete) for which an unshare is then
avoided. And with that, rxrpc_input_packet()
doesn't need to take a pointer to the pointer to
the packet, so change that to just a
pointer. |
| CVE-2026-45999 |
In the Linux kernel, the
following vulnerability has been resolved: erofs:
fix unsigned underflow in
z_erofs_lz4_handle_overlap() Some crafted images
can have illegal (!partial_decoding &&
m_llen < m_plen) extents, and the LZ4 inplace
decompression path can be wrongly hit, but it
cannot handle (outpages < inpages) properly:
"outpages - inpages" wraps to a large value and
the subsequent rq->out[] access reads past the
decompressed_pages array. However, such crafted
cases can correctly result in a corruption report
in the normal LZ4 non-inplace path. Let's add an
additional check to fix this for backporting.
Reproducible image (base64-encoded gzipped blob):
H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g
dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i
PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz
2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w
ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o
cache_strategy=disabled foo.erofs /mnt $ dd
if=/mnt/data of=/dev/null bs=4096 count=1 |
| CVE-2026-46000 |
In the Linux kernel, the
following vulnerability has been resolved: rxrpc:
Fix conn-level packet handling to unshare RESPONSE
packets The security operations that verify the
RESPONSE packets decrypt bits of it in place -
however, the sk_buff may be shared with a packet
sniffer, which would lead to the sniffer seeing an
apparently corrupt packet (actually decrypted).
Fix this by handing a copy of the packet off to
the specific security handler if the packet was
cloned. |
| CVE-2026-46002 |
In the Linux kernel, the
following vulnerability has been resolved: ext2:
reject inodes with zero i_nlink and valid mode in
ext2_iget() ext2_iget() already rejects inodes
with i_nlink == 0 when i_mode is zero or i_dtime
is set, treating them as deleted. However, the
case of i_nlink == 0 with a non-zero mode and zero
dtime slips through. Since ext2 has no orphan
list, such a combination can only result from
filesystem corruption - a legitimate inode
deletion always sets either i_dtime or clears
i_mode before freeing the inode. A crafted image
can exploit this gap to present such an inode to
the VFS, which then triggers WARN_ON inside
drop_nlink() (fs/inode.c) via ext2_unlink(),
ext2_rename() and ext2_rmdir(): WARNING: CPU: 3
PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0
fs/inode.c:336 CPU: 3 UID: 0 PID: 609 Comm:
syz-executor Not tainted 6.12.77+ #1 Call Trace:
<TASK> inode_dec_link_count
include/linux/fs.h:2518 [inline]
ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295
vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477
do_unlinkat+0x53e/0x730 fs/namei.c:4541
__x64_sys_unlink+0xc6/0x110 fs/namei.c:4587
do_syscall_64+0xf5/0x220
arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK> WARNING: CPU: 0 PID: 646 at
fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336
CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted
6.12.77+ #1 Call Trace: <TASK>
inode_dec_link_count include/linux/fs.h:2518
[inline] ext2_rename+0x35e/0x850
fs/ext2/namei.c:374 vfs_rename+0xf2f/0x2060
fs/namei.c:5021 do_renameat2+0xbe2/0xd50
fs/namei.c:5178 __x64_sys_rename+0x7e/0xa0
fs/namei.c:5223 do_syscall_64+0xf5/0x220
arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK> WARNING: CPU: 0 PID: 634 at
fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336
CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not
tainted 6.12.77+ #1 Call Trace: <TASK>
inode_dec_link_count include/linux/fs.h:2518
[inline] ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311
vfs_rmdir+0x204/0x690 fs/namei.c:4348
do_rmdir+0x372/0x3e0 fs/namei.c:4407
__x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577
do_syscall_64+0xf5/0x220
arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK> Extend the existing i_nlink == 0
check to also catch this case, reporting the
corruption via ext2_error() and returning
-EFSCORRUPTED. This rejects the inode at load time
and prevents it from reaching any of the namei.c
paths. Found by Linux Verification Center
(linuxtesting.org) with Syzkaller. |
| CVE-2026-46003 |
In the Linux kernel, the
following vulnerability has been resolved: net:
qrtr: ns: Limit the total number of nodes
Currently, the nameserver doesn't limit the number
of nodes it handles. This can be an attack vector
if a malicious client starts registering random
nodes, leading to memory exhaustion. Hence, limit
the maximum number of nodes to 64. Note that,
limit of 64 is chosen based on the current
platform requirements. If requirement changes in
the future, this limit can be increased. |
| CVE-2026-46004 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
caiaq: Handle probe errors properly The probe
procedure of setup_card() in caiaq driver doesn't
treat the error cases gracefully, e.g. the error
from snd_card_register() calls snd_card_free() but
continues. This would lead to a UAF for the
further calls like snd_usb_caiaq_control_init(),
as Berk suggested in another patch in the link
below. However, the problem is not only that; in
general, this function drops the all error
handlings (as it's a void function) although its
caller can propagate an error to snd_probe(),
which eventually calls snd_card_free() as a proper
error path. That said, we should treat each error
case in setup_card(), and just return the error
code promptly, which is then handled later as a
fatal error in snd_probe(). This patch achieves it
by changing the setup_card() to return an error
code. Also, the superfluous snd_card_free() call
is removed, too. Note that card->private_free
can be set still safely at returning an error. All
called functions in card_free() have checks of the
unassigned resources or NULL checks. |
| CVE-2026-46005 |
In the Linux kernel, the
following vulnerability has been resolved: xfs:
fix a resource leak in xfs_alloc_buftarg() In the
error path, call fs_put_dax() to drop the DAX
device reference. |
| CVE-2026-46006 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/nouveau: fix u32 overflow in pushbuf reloc
bounds check nouveau_gem_pushbuf_reloc_apply()
validates each relocation with if
(r->reloc_bo_offset + 4 >
nvbo->bo.base.size) but reloc_bo_offset is
__u32 (uapi/drm/nouveau_drm.h) and the integer
literal 4 promotes to unsigned int, so the
addition is performed in 32 bits and wraps before
the comparison against the size_t bo size. Cast to
u64 so the addition happens in 64-bit arithmetic.
[ Add Fixes: tag. - Danilo ] |
| CVE-2026-46007 |
In the Linux kernel, the
following vulnerability has been resolved: hwmon:
(powerz) Avoid cacheline sharing for DMA buffer
Depending on the architecture the transfer buffer
may share a cacheline with the following mutex. As
the buffer may be used for DMA, that is
problematic. Use the high-level DMA helpers to
make sure that cacheline sharing can not happen.
Also drop the comment, as the helpers are
documentation enough.
https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org |
| CVE-2026-46009 |
In the Linux kernel, the
following vulnerability has been resolved: PCI:
endpoint: pci-epf-ntb: Remove duplicate resource
teardown epf_ntb_epc_destroy() duplicates the
teardown that the caller is supposed to do later.
This leads to an oops when .allow_link fails or
when .drop_link is performed. Remove the helper.
Also drop pci_epc_put(). EPC device refcounting is
tied to configfs EPC group lifetime, and
pci_epc_put() in the .drop_link path is
sufficient. |
| CVE-2026-46011 |
In the Linux kernel, the
following vulnerability has been resolved: media:
mtk-jpeg: fix use-after-free in release path due
to uncancelled work The mtk_jpeg_release()
function frees the context structure (ctx) without
first cancelling any pending or running work in
ctx->jpeg_work. This creates a race window
where the workqueue callback may still be
accessing the context memory after it has been
freed. Race condition: CPU 0 (release) CPU 1
(workqueue) ---------------- ------------------
close() mtk_jpeg_release() mtk_jpegenc_worker()
ctx = work->data // accessing ctx kfree(ctx) //
freed! access ctx // UAF! The work is queued via
queue_work() during JPEG encode/decode operations
(via mtk_jpeg_device_run). If the device is closed
while work is pending or running, the work handler
will access freed memory. Fix this by calling
cancel_work_sync() BEFORE acquiring the mutex.
This ordering is critical: if cancel_work_sync()
is called after mutex_lock(), and the work handler
also tries to acquire the same mutex, it would
cause a deadlock. Note: The open error path does
NOT need cancel_work_sync() because INIT_WORK()
only initializes the work structure - it does not
schedule it. Work is only scheduled later during
ioctl operations. |
| CVE-2026-46012 |
In the Linux kernel, the
following vulnerability has been resolved: rxrpc:
Fix memory leaks in rxkad_verify_response() Fix
rxkad_verify_response() to free the ticket and the
server key under all circumstances by initialising
the ticket pointer to NULL and then making all
paths through the function after the first
allocation has been done go through a single
common epilogue that just releases everything -
where all the releases skip on a NULL
pointer. |
| CVE-2026-46014 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
SVM: Add missing save/restore handling of LBR MSRs
MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently
not enumerated by KVM_GET_MSR_INDEX_LIST, and LBR
MSRs cannot be set with KVM_SET_MSRS. So
save/restore is completely broken. Fix it by
adding the MSRs to msrs_to_save_base, and allowing
writes to LBR MSRs from userspace only (as they
are read-only MSRs) if LBR virtualization is
enabled. Additionally, to correctly restore L1's
LBRs while L2 is running, make sure the LBRs are
copied from the captured VMCB01 save area in
svm_copy_vmrun_state(). Note, for VMX, this also
fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't
reported as an MSR to save/restore. Note #2,
over-reporting MSR_IA32_LASTxxx on Intel is ok, as
KVM already handles unsupported reads and writes
thanks to commit b5e2fec0ebc3 ("KVM: Ignore
DEBUGCTL MSRs with no effect")
(kvm_do_msr_access() will morph the unsupported
userspace write into a nop). [sean: guard with
lbrv checks, massage changelog] |
| CVE-2026-46015 |
In the Linux kernel, the
following vulnerability has been resolved: tcp:
call sk_data_ready() after listener migration When
inet_csk_listen_stop() migrates an established
child socket from a closing listener to another
socket in the same SO_REUSEPORT group, the target
listener gets a new accept-queue entry via
inet_csk_reqsk_queue_add(), but that path never
notifies the target listener's waiters. A
nonblocking accept() still works because it checks
the queue directly, but poll()/epoll_wait()
waiters and blocking accept() callers can also
remain asleep indefinitely. Call
READ_ONCE(nsk->sk_data_ready)(nsk) after a
successful migration in inet_csk_listen_stop().
However, after inet_csk_reqsk_queue_add()
succeeds, the ref acquired in
reuseport_migrate_sock() is effectively
transferred to nreq->rsk_listener. Another CPU
can then dequeue nreq via accept() or listener
shutdown, hit reqsk_put(), and drop that listener
ref. Since listeners are SOCK_RCU_FREE, wrap the
post-queue_add() dereferences of nsk in
rcu_read_lock()/rcu_read_unlock(), which also
covers the existing sock_net(nsk) access in that
path. The reqsk_timer_handler() path does not need
the same changes for two reasons: half-open
requests become readable only after the final ACK,
where tcp_child_process() already wakes the
listener; and once nreq is visible via
inet_ehash_insert(), the success path no longer
touches nsk directly. |
| CVE-2026-46016 |
In the Linux kernel, the
following vulnerability has been resolved:
remoteproc: xlnx: Only access buffer information
if IPI is buffered In the receive callback check
if message is NULL to prevent possibility of crash
by NULL pointer dereferencing. |
| CVE-2026-46018 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
usb-audio: stop parsing UAC2 rates at MAX_NR_RATES
parse_uac2_sample_rate_range() caps the number of
enumerated rates at MAX_NR_RATES, but it only
breaks out of the current rate loop. A malformed
UAC2 RANGE response with additional triplets
continues parsing the remaining triplets and
repeatedly prints "invalid uac2 rates" while probe
still holds register_mutex. Stop the whole parse
once the cap is reached and return the number of
rates collected so far. |
| CVE-2026-46019 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
atmel-aes - Fix 3-page memory leak in
atmel_aes_buff_cleanup atmel_aes_buff_init()
allocates 4 pages using __get_free_pages() with
ATMEL_AES_BUFFER_ORDER, but
atmel_aes_buff_cleanup() frees only the first page
using free_page(), leaking the remaining 3 pages.
Use free_pages() with ATMEL_AES_BUFFER_ORDER to
fix the memory leak. |
| CVE-2026-46021 |
In the Linux kernel, the
following vulnerability has been resolved:
thermal: core: Fix thermal zone governor cleanup
issues If
thermal_zone_device_register_with_trips() fails
after adding a thermal governor to the thermal
zone being registered, the governor is not removed
from it as appropriate which may lead to a memory
leak. In turn, thermal_zone_device_unregister()
calls thermal_set_governor() without acquiring the
thermal zone lock beforehand which may race with a
governor update via sysfs and may lead to a
use-after-free in that case. Address these issues
by adding two thermal_set_governor() calls, one to
thermal_release() to remove the governor from the
given thermal zone, and one to the thermal zone
registration error path to cover failures
preceding the thermal zone device
registration. |
| CVE-2026-46022 |
In the Linux kernel, the
following vulnerability has been resolved: misc:
ibmasm: fix OOB MMIO read in
ibmasm_handle_mouse_interrupt()
ibmasm_handle_mouse_interrupt() performs an
out-of-bounds MMIO read when the queue reader or
writer index from hardware exceeds
REMOTE_QUEUE_SIZE (60). A compromised service
processor can trigger this by writing an
out-of-range value to the reader or writer MMIO
register before asserting an interrupt. Since
writer is re-read from hardware on every loop
iteration, it can also be set to an out-of-range
value after the loop has already started. The root
cause is that get_queue_reader() and
get_queue_writer() return raw readl() values that
are passed directly into get_queue_entry(), which
computes: queue_begin + reader * sizeof(struct
remote_input) with no bounds check. This unchecked
MMIO address is then passed to memcpy_fromio(),
reading 8 bytes from unintended device registers.
For sufficiently large values the address falls
outside the PCI BAR mapping entirely, triggering a
machine check exception. Fix by checking both
indices against REMOTE_QUEUE_SIZE at the top of
the loop body, before any call to
get_queue_entry(). On an out-of-range value, reset
the reader register to 0 via set_queue_reader()
before breaking, so that normal queue operation
can resume if the corrupted hardware state is
transient. |
| CVE-2026-46023 |
In the Linux kernel, the
following vulnerability has been resolved: dm
mirror: fix integer overflow in create_dirty_log()
The argument count calculation in
create_dirty_log() performs `*args_used = 2 +
param_count` before validating against argc. When
a user provides a param_count close to UINT_MAX
via the device mapper table string, this unsigned
addition wraps around to a small value, causing
the subsequent `argc < *args_used` check to be
bypassed. The overflowed param_count is then
passed as argc to dm_dirty_log_create(), where it
can cause out-of-bounds reads on the argv array.
Fix by comparing param_count against argc - 2
before performing the addition, following the same
pattern used by parse_features() in the same file.
Since argc >= 2 is already guaranteed, the
subtraction is safe. |
| CVE-2026-46024 |
In the Linux kernel, the
following vulnerability has been resolved:
libceph: Prevent potential null-ptr-deref in
ceph_handle_auth_reply() If a message of type
CEPH_MSG_AUTH_REPLY contains a zero value for both
protocol and result, this is currently not treated
as an error. In case of ac->negotiating == true
and ac->protocol > 0, this leads to setting
ac->protocol = 0 and ac->ops = NULL.
Thereafter, the check for ac->protocol !=
protocol returns false, and init_protocol() is not
called. Subsequently,
ac->ops->handle_reply() is called, which
leads to a null pointer dereference, because
ac->ops is still NULL. This patch changes the
check for ac->protocol != protocol to
!ac->protocol, as this also includes the case
when the protocol was set to zero in the message.
This causes the message to be treated as
containing a bad auth protocol. |
| CVE-2026-46026 |
In the Linux kernel, the
following vulnerability has been resolved: net:
qrtr: ns: Limit the maximum number of lookups
Current code does no bound checking on the number
of lookups a client can perform. Though the code
restricts the lookups to local clients, there is
still a possibility of a malicious local client
sending a flood of NEW_LOOKUP messages over the
same socket. Fix this issue by limiting the
maximum number of lookups to 64 globally. Since
the nameserver allows only atmost one local
observer, this global lookup count will ensure
that the lookups stay within the limit. Note that,
limit of 64 is chosen based on the current
platform requirements. If requirement changes in
the future, this limit can be increased. |
| CVE-2026-46027 |
In the Linux kernel, the
following vulnerability has been resolved:
net/smc: avoid early lgr access in
smc_clc_wait_msg A CLC decline can be received
while the handshake is still in an early stage,
before the connection has been associated with a
link group. The decline handling in
smc_clc_wait_msg() updates link-group level sync
state for first-contact declines, but that state
only exists after link group setup has completed.
Guard the link-group update accordingly and keep
the per-socket peer diagnosis handling unchanged.
This preserves the existing sync_err handling for
established link-group contexts and avoids
touching link-group state before it is
available. |
| CVE-2026-46028 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
algif_aead - snapshot IV for async AEAD requests
AF_ALG AEAD AIO requests currently use the
socket-wide IV buffer during request processing.
For async requests, later socket activity can
update that shared state before the original
request has fully completed, which can lead to
inconsistent IV handling. Snapshot the IV into
per-request storage when preparing the AEAD
request, so in-flight operations no longer depend
on mutable socket state. |
| CVE-2026-46031 |
In the Linux kernel, the
following vulnerability has been resolved: net:
ks8851: Reinstate disabling of BHs around IRQ
handler If the driver executes ks8851_irq() AND a
TX packet has been sent, then the driver enables
TX queue via netif_wake_queue() which schedules TX
softirq to queue packets for this device. If
CONFIG_PREEMPT_RT=y is set AND a packet has also
been received by the MAC, then ks8851_rx_pkts()
calls netdev_alloc_skb_ip_align() to allocate SKBs
for the received packets. If
netdev_alloc_skb_ip_align() is called with BH
enabled, then local_bh_enable() at the end of
netdev_alloc_skb_ip_align() will trigger the
pending softirq processing, which may ultimately
call the .xmit callback ks8851_start_xmit_par().
The ks8851_start_xmit_par() will try to lock
struct ks8851_net_par .lock spinlock, which is
already locked by ks8851_irq() from which
ks8851_start_xmit_par() was called. This leads to
a deadlock, which is reported by the kernel,
including a trace listed below. If
CONFIG_PREEMPT_RT is not set, then since commit
0913ec336a6c0 ("net: ks8851: Fix deadlock with the
SPI chip variant") the deadlock can also be
triggered without received packet in the RX FIFO.
The pending softirqs will be processed on return
from spin_unlock_bh(&ks->statelock) in
ks8851_irq(), which triggers the deadlock as well.
Fix the problem by disabling BH around critical
sections, including the IRQ handler, thus
preventing the net_tx_action() softirq from
triggering during these critical sections. The
net_tx_action() softirq is triggered once BH are
re-enabled and at the end of the IRQ handler, once
all the other IRQ handler actions have been
completed. __schedule from
schedule_rtlock+0x1c/0x34 schedule_rtlock from
rtlock_slowlock_locked+0x548/0x904
rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c
rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8
ks8851_start_xmit_par from
netdev_start_xmit+0x20/0x44 netdev_start_xmit from
dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit
from sch_direct_xmit+0xb8/0x25c sch_direct_xmit
from __qdisc_run+0x1f8/0x4ec __qdisc_run from
qdisc_run+0x1c/0x28 qdisc_run from
net_tx_action+0x1f0/0x268 net_tx_action from
handle_softirqs+0x1a4/0x270 handle_softirqs from
__local_bh_enable_ip+0xcc/0xe0
__local_bh_enable_ip from __alloc_skb+0xd8/0x128
__alloc_skb from __netdev_alloc_skb+0x3c/0x19c
__netdev_alloc_skb from ks8851_irq+0x388/0x4d4
ks8851_irq from irq_thread_fn+0x24/0x64
irq_thread_fn from irq_thread+0x178/0x28c
irq_thread from kthread+0x12c/0x138 kthread from
ret_from_fork+0x14/0x28 |
| CVE-2026-46032 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
nSVM: Triple fault if restore host CR3 fails on
nested #VMEXIT If loading L1's CR3 fails on a
nested #VMEXIT, nested_svm_vmexit() returns an
error code that is ignored by most callers, and
continues to run L1 with corrupted state. A sane
recovery is not possible in this case, and HW
behavior is to cause a shutdown. Inject a triple
fault instead, and do not return early from
nested_svm_vmexit(). Continue cleaning up the vCPU
state (e.g. clear pending exceptions), to handle
the failure as gracefully as possible. From the
APM: Upon #VMEXIT, the processor performs the
following actions in order to return to the host
execution context: ... if (illegal host state
loaded, or exception while loading host state)
shutdown else execute first host instruction
following the VMRUN Remove the return value of
nested_svm_vmexit(), which is mostly unchecked
anyway. |
| CVE-2026-46033 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
authencesn - reject short ahash digests during
instance creation authencesn requires either a
zero authsize or an authsize of at least 4 bytes
because the ESN encrypt/decrypt paths always move
4 bytes of high-order sequence number data at the
end of the authenticated data. While
crypto_authenc_esn_setauthsize() already rejects
explicit non-zero authsizes in the range 1..3,
crypto_authenc_esn_create() still copied
auth->digestsize into inst->alg.maxauthsize
without validating it. The AEAD core then
initialized the tfm's default authsize from that
value. As a result, selecting an ahash with digest
size 1..3, such as cbcmac(cipher_null), exposed
authencesn instances whose default authsize was
invalid even though setauthsize() would have
rejected the same value. AF_ALG could then trigger
the ESN tail handling with a too-short tag and hit
an out-of-bounds access. Reject authencesn
instances whose ahash digest size is in the
invalid non-zero range 1..3 so that no tfm can
inherit an unsupported default authsize. |
| CVE-2026-46037 |
In the Linux kernel, the
following vulnerability has been resolved: ipv4:
icmp: validate reply type before using
icmp_pointers Extended echo replies use
ICMP_EXT_ECHOREPLY as the outbound reply type.
That value is outside the range covered by
icmp_pointers[], which only describes the
traditional ICMP types up to NR_ICMP_TYPES. Avoid
consulting icmp_pointers[] for reply types outside
that range, and use array_index_nospec() for the
remaining in-range lookup. Normal ICMP replies
keep their existing behavior unchanged. |
| CVE-2026-46038 |
In the Linux kernel, the
following vulnerability has been resolved: net:
qrtr: ns: Free the node during ctrl_cmd_bye() A
node sends the BYE packet when it is about to go
down. So the nameserver should advertise the
removal of the node to all remote and local
observers and free the node finally. But
currently, the nameserver doesn't free the node
memory even after processing the BYE packet. This
causes the node memory to leak. Hence, remove the
node from Xarray list and free the node memory
during both success and failure case of
ctrl_cmd_bye(). |
| CVE-2026-46040 |
In the Linux kernel, the
following vulnerability has been resolved:
inotify: fix watch count leak when
fsnotify_add_inode_mark_locked() fails When
fsnotify_add_inode_mark_locked() fails in
inotify_new_watch(), the error path calls
inotify_remove_from_idr() but does not call
dec_inotify_watches() to undo the preceding
inc_inotify_watches(). This leaks a watch count,
and repeated failures can exhaust the
max_user_watches limit with -ENOSPC even when no
watches are active. Prior to commit 1cce1eea0aff
("inotify: Convert to using per-namespace
limits"), the watch count was incremented after
fsnotify_add_mark_locked() succeeded, so this path
was not affected. The conversion moved
inc_inotify_watches() before the mark insertion
without adding the corresponding rollback. Add the
missing dec_inotify_watches() call in the error
path. |
| CVE-2026-46041 |
In the Linux kernel, the
following vulnerability has been resolved:
greybus: gb-beagleplay: fix sleep in atomic
context in hdlc_tx_frames() hdlc_append() calls
usleep_range() to wait for circular buffer space,
but it is called with tx_producer_lock (a
spinlock) held via hdlc_tx_frames() ->
hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc.
Sleeping while holding a spinlock is illegal and
can trigger "BUG: scheduling while atomic". Fix
this by moving the buffer-space wait out of
hdlc_append() and into hdlc_tx_frames(), before
the spinlock is acquired. The new flow: 1.
Pre-calculate the worst-case encoded frame length.
2. Wait (with sleep) outside the lock until enough
space is available, kicking the TX consumer work
to drain the buffer. 3. Acquire the spinlock,
re-verify space, and write the entire frame
atomically. This ensures that sleeping only
happens without any lock held, and that frames are
either fully enqueued or not written at all. This
bug is found by CodeQL static analysis tool
(interprocedural sleep-in-atomic query) and my
code review. |
| CVE-2026-46043 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/rxe: Validate pad and ICRC before
payload_size() in rxe_rcv rxe_rcv() currently
checks only that the incoming packet is at least
header_size(pkt) bytes long before payload_size()
is used. However, payload_size() subtracts both
the attacker-controlled BTH pad field and
RXE_ICRC_SIZE from pkt->paylen: payload_size =
pkt->paylen - offset[RXE_PAYLOAD] -
bth_pad(pkt) - RXE_ICRC_SIZE This means a short
packet can still make payload_size() underflow
even if it includes enough bytes for the fixed
headers. Simply requiring header_size(pkt) +
RXE_ICRC_SIZE is not sufficient either, because a
packet with a forged non-zero BTH pad can still
leave payload_size() negative and pass an
underflowed value to later receive-path users. Fix
this by validating pkt->paylen against the full
minimum length required by payload_size():
header_size(pkt) + bth_pad(pkt) +
RXE_ICRC_SIZE. |
| CVE-2026-46044 |
In the Linux kernel, the
following vulnerability has been resolved:
ipmi:ssif: Clean up kthread on errors If an error
occurs after the ssif kthread is created, but
before the main IPMI code starts the ssif
interface, the ssif kthread will not be stopped.
So make sure the kthread is stopped on an error
condition if it is running. |
| CVE-2026-46046 |
In the Linux kernel, the
following vulnerability has been resolved: ext4:
fix missing brelse() in
ext4_xattr_inode_dec_ref_all() The commit
c8e008b60492 ("ext4: ignore xattrs past end")
introduced a refcount leak in when block_csum is
false. ext4_xattr_inode_dec_ref_all() calls
ext4_get_inode_loc() to get iloc.bh, but never
releases it with brelse(). |
| CVE-2026-46047 |
In the Linux kernel, the
following vulnerability has been resolved: net:
qrtr: ns: Fix use-after-free in driver remove() In
the remove callback, if a packet arrives after
destroy_workqueue() is called, but before
sock_release(), the qrtr_ns_data_ready() callback
will try to queue the work, causing use-after-free
issue. Fix this issue by saving the default
'sk_data_ready' callback during qrtr_ns_init() and
use it to replace the qrtr_ns_data_ready()
callback at the start of remove(). This ensures
that even if a packet arrives after
destroy_workqueue(), the work struct will not be
dereferenced. Note that it is also required to
ensure that the RX threads are completed before
destroying the workqueue, because the threads
could be using the qrtr_ns_data_ready()
callback. |
| CVE-2026-46049 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
ctxfi: Add fallback to default RSR for S/PDIF
spdif_passthru_playback_get_resources() uses
atc->pll_rate as the RSR for the MSR
calculation loop. However, pll_rate is only
updated in atc_pll_init() and not in
hw_pll_init(), so it remains 0 after the card
init. When spdif_passthru_playback_setup() skips
atc_pll_init() for 32000 Hz, (rsr * desc.msr)
always becomes 0, causing the loop to spin
indefinitely. Add fallback to use atc->rsr when
atc->pll_rate is 0. This reflects the hardware
state, since hw_card_init() already configures the
PLL to the default RSR. |
| CVE-2026-46050 |
In the Linux kernel, the
following vulnerability has been resolved:
md/raid10: fix deadlock with check operation and
nowait requests When an array check is running it
will raise the barrier at which point normal
requests will become blocked and increment the
nr_pending value to signal there is work pending
inside of wait_barrier(). NOWAIT requests do not
block and so will return immediately with an
error, and additionally do not increment
nr_pending in wait_barrier(). Upstream change
commit 43806c3d5b9b ("raid10: cleanup memleak at
raid10_make_request") added a call to
raid_end_bio_io() to fix a memory leak when NOWAIT
requests hit this condition. raid_end_bio_io()
eventually calls allow_barrier() and it will
unconditionally do an
atomic_dec_and_test(&conf->nr_pending) even
though the corresponding increment on nr_pending
didn't happen in the NOWAIT case. This can be
easily seen by starting a check operation while an
application is doing nowait IO on the same array.
This results in a deadlocked state due to
nr_pending value underflowing and so the md resync
thread gets stuck waiting for nr_pending to == 0.
Output of r10conf state of the array when we hit
this condition: crash> struct r10conf barrier =
1, nr_pending = { counter = -41 }, nr_waiting =
15, nr_queued = 0, Example of md_sync thread stuck
waiting on raise_barrier() and other requests
stuck in wait_barrier(): md1_resync [<0>]
raise_barrier+0xce/0x1c0 [<0>]
raid10_sync_request+0x1ca/0x1ed0 [<0>]
md_do_sync+0x779/0x1110 [<0>]
md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0
[<0>] ret_from_fork+0x34/0x50 [<0>]
ret_from_fork_asm+0x1a/0x30
kworker/u1040:2+flush-253:4 [<0>]
wait_barrier+0x1de/0x220 [<0>]
regular_request_wait+0x30/0x180 [<0>]
raid10_make_request+0x261/0x1000 [<0>]
md_handle_request+0x13b/0x230 [<0>]
__submit_bio+0x107/0x1f0 [<0>]
submit_bio_noacct_nocheck+0x16f/0x390 [<0>]
ext4_io_submit+0x24/0x40 [<0>]
ext4_do_writepages+0x254/0xc80 [<0>]
ext4_writepages+0x84/0x120 [<0>]
do_writepages+0x7a/0x260 [<0>]
__writeback_single_inode+0x3d/0x300 [<0>]
writeback_sb_inodes+0x1dd/0x470 [<0>]
__writeback_inodes_wb+0x4c/0xe0 [<0>]
wb_writeback+0x18b/0x2d0 [<0>]
wb_workfn+0x2a1/0x400 [<0>]
process_one_work+0x149/0x330 [<0>]
worker_thread+0x2d2/0x410 [<0>]
kthread+0xbe/0xf0 [<0>]
ret_from_fork+0x34/0x50 [<0>]
ret_from_fork_asm+0x1a/0x30 |
| CVE-2026-46051 |
In the Linux kernel, the
following vulnerability has been resolved:
md/raid5: fix soft lockup in retry_aligned_read()
When retry_aligned_read() encounters an overlapped
stripe, it releases the stripe via
raid5_release_stripe() which puts it on the
lockless released_stripes llist. In the next
raid5d loop iteration, release_stripe_list()
drains the stripe onto handle_list (since
STRIPE_HANDLE is set by the original IO), but
retry_aligned_read() runs before
handle_active_stripes() and removes the stripe
from handle_list via find_get_stripe() ->
list_del_init(). This prevents handle_stripe()
from ever processing the stripe to resolve the
overlap, causing an infinite loop and soft lockup.
Fix this by using __release_stripe() with
temp_inactive_list instead of
raid5_release_stripe() in the failure path, so the
stripe does not go through the released_stripes
llist. This allows raid5d to break out of its
loop, and the overlap will be resolved when the
stripe is eventually processed by
handle_stripe(). |
| CVE-2026-46052 |
In the Linux kernel, the
following vulnerability has been resolved: ceph:
only d_add() negative dentries when they are
unhashed Ceph can call d_add(dentry, NULL) on a
negative dentry that is already present in the
primary dcache hash. In the current VFS that is
not safe. d_add() goes through __d_add() to
__d_rehash(), which unconditionally reinserts
dentry->d_hash into the hlist_bl bucket. If the
dentry is already hashed, reinserting the same
node can corrupt the bucket, including creating a
self-loop. Once that happens, __d_lookup() can
spin forever in the hlist_bl walk, typically
looping only on the d_name.hash mismatch check and
eventually triggering RCU stall reports like this
one: rcu: INFO: rcu_sched self-detected stall on
CPU rcu: 87-....: (2100 ticks this GP)
idle=3a4c/1/0x4000000000000000
softirq=25003319/25003319 fqs=829 rcu: (t=2101
jiffies g=79058445 q=698988 ncpus=192) CPU: 87
UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not
tainted 6.18.17-i1-amd #950 NONE Hardware name:
Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6
09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1
e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89
c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00
00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3
48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP:
0018:ff745a70c8253898 EFLAGS: 00000282 RAX:
ff26e470054cb208 RBX: ff26e470054cb208 RCX:
000000006e958966 RDX: ff26e48267340000 RSI:
ff745a70c82539b0 RDI: ff26e458f74655c0 RBP:
000000006e958966 R08: 0000000000000180 R09:
9cd08d909b919a89 R10: ff26e458f74655c0 R11:
0000000000000000 R12: ff26e458f74655c0 R13:
ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15:
2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000)
GS:ff26e482c5d88000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4:
0000000000771ef0 PKRU: 55555554 Call Trace:
<TASK> lookup_fast+0x9f/0x100
walk_component+0x1f/0x150
link_path_walk+0x20e/0x3d0
path_lookupat+0x68/0x180
filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140
vfs_fstatat+0x67/0xa0
__do_sys_newfstatat+0x24/0x60
do_syscall_64+0x6a/0x230
entry_SYSCALL_64_after_hwframe+0x76/0x7e This is
reachable with reused cached negative dentries. A
Ceph lookup or atomic_open can be handed a
negative dentry that is already hashed, and
fs/ceph/dir.c then hits one of two paths that
incorrectly assume "negative" also means
"unhashed": - ceph_finish_lookup(): MDS reply is
-ENOENT with no trace -> d_add(dentry, NULL) -
ceph_lookup(): local ENOENT fast path for a
complete directory with shared caps ->
d_add(dentry, NULL) Both paths can therefore
re-add an already-hashed negative dentry. Ceph
already uses the correct pattern elsewhere:
ceph_fill_trace() only calls d_add(dn, NULL) for a
negative null-dentry reply when d_unhashed(dn) is
true. Fix both fs/ceph/dir.c sites the same way:
only call d_add() for a negative dentry when it is
actually unhashed. If the negative dentry is
already hashed, leave it in place and reuse it
as-is. This preserves the existing behavior for
unhashed dentries while avoiding d_hash list
corruption for reused hashed negatives. |
| CVE-2026-46053 |
In the Linux kernel, the
following vulnerability has been resolved: net:
rds: fix MR cleanup on copy error __rds_rdma_map()
hands sg/pages ownership to the transport after
get_mr() succeeds. If copying the generated cookie
back to user space fails after that point, the
error path must not free those resources again
before dropping the MR reference. Remove the
duplicate unpin/free from the put_user() failure
branch so that MR teardown is handled only through
the existing final cleanup path. |
| CVE-2026-46054 |
In the Linux kernel, the
following vulnerability has been resolved:
selinux: fix overlayfs mmap() and mprotect()
access checks The existing SELinux security model
for overlayfs is to allow access if the current
task is able to access the top level file (the
"user" file) and the mounter's credentials are
sufficient to access the lower level file (the
"backing" file). Unfortunately, the current code
does not properly enforce these access controls
for both mmap() and mprotect() operations on
overlayfs filesystems. This patch makes use of the
newly created security_mmap_backing_file() LSM
hook to provide the missing backing file
enforcement for mmap() operations, and leverages
the backing file API and new LSM blob to provide
the necessary information to properly enforce the
mprotect() access controls. |
| CVE-2026-46056 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: hci_event: fix potential UAF in SSP
passkey handlers hci_conn lookup and field access
must be covered by hdev lock in
hci_user_passkey_notify_evt() and
hci_keypress_notify_evt(), otherwise the
connection can be freed concurrently. Extend the
hci_dev_lock critical section to cover all conn
usage in both handlers. Keep the existing keypress
notification behavior unchanged by routing the
early exits through a common unlock path. |
| CVE-2026-46058 |
In the Linux kernel, the
following vulnerability has been resolved: media:
amphion: Fix race between m2m job_abort and
device_run Fix kernel panic caused by race
condition where v4l2_m2m_ctx_release() frees
m2m_ctx while v4l2_m2m_try_run() is about to call
device_run with the same context. Race sequence:
v4l2_m2m_try_run(): v4l2_m2m_ctx_release():
lock/unlock v4l2_m2m_cancel_job() job_abort()
v4l2_m2m_job_finish() kfree(m2m_ctx) <- frees
ctx device_run() <- use-after-free crash at
0x538 Crash trace: Unable to handle kernel read
from unreadable memory at virtual address
0000000000000538 v4l2_m2m_try_run+0x78/0x138
v4l2_m2m_device_run_work+0x14/0x20 The amphion vpu
driver does not rely on the m2m framework's
device_run callback to perform encode/decode
operations. Fix the race by preventing m2m
framework job scheduling entirely: - Add job_ready
callback returning 0 (no jobs ready for m2m
framework) - Remove job_abort callback to avoid
the race condition |
| CVE-2026-46059 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
nSVM: Always use NextRIP as vmcb02's NextRIP after
first L2 VMRUN For guests with NRIPS disabled, L1
does not provide NextRIP when running an L2 with
an injected soft interrupt, instead it advances
the current RIP before running it. KVM uses the
current RIP as the NextRIP in vmcb02 to emulate a
CPU without NRIPS. However, after L2 runs the
first time, NextRIP will be updated by the CPU
and/or KVM, and the current RIP is no longer the
correct value to use in vmcb02. Hence, after
save/restore, use the current RIP if and only if a
nested run is pending, otherwise use NextRIP. Give
soft_int_next_rip the same treatment, as it's the
same logic, just for a narrower use case. [sean:
give soft_int_next_rip the same treatment] |
| CVE-2026-46061 |
In the Linux kernel, the
following vulnerability has been resolved: jbd2:
fix deadlock in jbd2_journal_cancel_revoke()
Commit f76d4c28a46a ("fs/jbd2: use sleeping
version of __find_get_block()") changed
jbd2_journal_cancel_revoke() to use
__find_get_block_nonatomic() which holds the folio
lock instead of i_private_lock. This breaks the
lock ordering (folio -> buffer) and causes an
ABBA deadlock when the filesystem blocksize <
pagesize: T1 T2 ext4_mkdir() ext4_init_new_dir()
ext4_append() ext4_getblk() lock_buffer() <- A
sync_blockdev() blkdev_writepages()
writeback_iter() writeback_get_folio()
folio_lock() <- B
ext4_journal_get_create_access()
jbd2_journal_cancel_revoke()
__find_get_block_nonatomic() folio_lock() <- B
block_write_full_folio() lock_buffer() <- A
This can occasionally cause generic/013 to hang.
Fix by only calling __find_get_block_nonatomic()
when the passed buffer_head doesn't belong to the
bdev, which is the only case that we need to look
up its bdev alias. Otherwise, the lookup is
redundant since the found buffer_head is equal to
the one we passed in. |
| CVE-2026-46062 |
In the Linux kernel, the
following vulnerability has been resolved: ntfs3:
fix integer overflow in run_unpack() volume
boundary check The volume boundary check `lcn +
len > sbi->used.bitmap.nbits` uses raw
addition which can wrap around for large lcn and
len values, bypassing the validation. Use
check_add_overflow() as is already done for the
adjacent prev_lcn + dlcn and vcn64 + len checks
added by commit 3ac37e100385 ("ntfs3: Fix integer
overflow in run_unpack()"). Found by fuzzing with
a source-patched harness (LibAFL + QEMU). |
| CVE-2026-46063 |
In the Linux kernel, the
following vulnerability has been resolved:
x86/shstk: Prevent deadlock during shstk sigreturn
During sigreturn the shadow stack signal frame is
popped. The kernel does this by reading the shadow
stack using normal read accesses. When it can't
assume the memory is shadow stack, it takes extra
steps to makes sure it is reading actual shadow
stack memory and not other normal readable memory.
It does this by holding the mmap read lock while
doing the access and checking the flags of the
VMA. Unfortunately that is not safe. If the read
of the shadow stack sigframe hits a page fault,
the fault handler will try to recursively grab
another mmap read lock. This normally works ok,
but if a writer on another CPU is also waiting,
the second read lock could fail and cause a
deadlock. Fix this by not holding mmap lock during
the read access to userspace. Instead use
mmap_lock_speculate_...() to watch for changes
between dropping mmap lock and the userspace
access. Retry if anything grabbed an mmap write
lock in between and could have changed the VMA.
These mmap_lock_speculate_...() helpers use
mm::mm_lock_seq, which is only available when
PER_VMA_LOCK is configured. So make
X86_USER_SHADOW_STACK depend on it. On x86,
PER_VMA_LOCK is a default configuration for SMP
kernels. So drop support for the other configs
under the assumption that the !SMP shadow stack
user base does not exist. Currently there is a
check that skips the lookup work when the SSP can
be assumed to be on a shadow stack. While
reorganizing the function, remove the optimization
to make the tricky code flows more common, such
that issues like this cannot escape detection for
so long. |
| CVE-2026-46064 |
In the Linux kernel, the
following vulnerability has been resolved: ibmasm:
fix heap over-read in ibmasm_send_i2o_message()
The ibmasm_send_i2o_message() function uses
get_dot_command_size() to compute the byte count
for memcpy_toio(), but this value is derived from
user-controlled fields in the dot_command_header
(command_size: u8, data_size: u16) and is never
validated against the actual allocation size. A
root user can write a small buffer with inflated
header fields, causing memcpy_toio() to read up to
~65 KB past the end of the allocation into
adjacent kernel heap, which is then forwarded to
the service processor over MMIO. Silently clamping
the copy size is not sufficient: if the header
fields claim a larger size than the buffer, the SP
receives a dot command whose own header is
inconsistent with the I2O message length, which
can cause the SP to desynchronize. Reject such
commands outright by returning failure. Validate
command_size before calling get_mfa_inbound() to
avoid leaking an I2O message frame: reading
INBOUND_QUEUE_PORT dequeues a hardware frame from
the controller's free pool, and returning without
a corresponding set_mfa_inbound() call would
permanently exhaust it. Additionally, clamp
command_size to I2O_COMMAND_SIZE before the
memcpy_toio() so the MMIO write stays within the
I2O message frame, consistent with the clamping
already performed by outgoing_message_size() for
the header field. |
| CVE-2026-46065 |
In the Linux kernel, the
following vulnerability has been resolved: fbdev:
defio: Disconnect deferred I/O from the lifetime
of struct fb_info Hold state of deferred I/O in
struct fb_deferred_io_state. Allocate an instance
as part of initializing deferred I/O and remove it
only after the final mapping has been closed. If
the fb_info and the contained deferred I/O
meanwhile goes away, clear struct
fb_deferred_io_state.info to invalidate the
mapping. Any access will then result in a SIGBUS
signal. Fixes a long-standing problem, where a
device hot-unplug happens while user space still
has an active mapping of the graphics memory. The
hot- unplug frees the instance of struct fb_info.
Accessing the memory will operate on undefined
state. |
| CVE-2026-46066 |
In the Linux kernel, the
following vulnerability has been resolved: ceph:
fix num_ops off-by-one when crypto allocation
fails move_dirty_folio_in_page_array() may fail if
the file is encrypted, the dirty folio is not the
first in the batch, and it fails to allocate a
bounce buffer to hold the ciphertext. When that
happens, ceph_process_folio_batch() simply
redirties the folio and flushes the current batch
-- it can retry that folio in a future batch.
However, if this failed folio is not contiguous
with the last folio that did make it into the
batch, then ceph_process_folio_batch() has already
incremented `ceph_wbc->num_ops`; because it
doesn't follow through and add the discontiguous
folio to the array, ceph_submit_write() -- which
expects that `ceph_wbc->num_ops` accurately
reflects the number of contiguous ranges (and
therefore the required number of "write extent"
ops) in the writeback -- will panic the kernel:
BUG_ON(ceph_wbc->op_idx + 1 !=
req->r_num_ops); This issue can be reproduced
on affected kernels by writing to fscrypt-enabled
CephFS file(s) with a
4KiB-written/4KiB-skipped/repeat pattern (total
filesize should not matter) and gradually
increasing the system's memory pressure until a
bounce buffer allocation fails. Fix this crash by
decrementing `ceph_wbc->num_ops` back to the
correct value when
move_dirty_folio_in_page_array() fails, but the
folio already started counting a new (i.e.
still-empty) extent. The defect corrected by this
patch has existed since 2022 (see first `Fixes:`),
but another bug blocked multi-folio encrypted
writeback until recently (see second `Fixes:`).
The second commit made it into 6.18.16, 6.19.6,
and 7.0-rc1, unmasking the panic in those
versions. This patch therefore fixes a regression
(panic) introduced by cac190c7674f. |
| CVE-2026-46068 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
nx - fix bounce buffer leaks in
nx842_crypto_{alloc,free}_ctx The bounce buffers
are allocated with __get_free_pages() using
BOUNCE_BUFFER_ORDER (order 2 = 4 pages), but both
the allocation error path and
nx842_crypto_free_ctx() release the buffers with
free_page(). Use free_pages() with the matching
order instead. |
| CVE-2026-46069 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
mwifiex: fix use-after-free in
mwifiex_adapter_cleanup() The
mwifiex_adapter_cleanup() function uses
timer_delete() (non-synchronous) for the
wakeup_timer before the adapter structure is
freed. This is incorrect because timer_delete()
does not wait for any running timer callback to
complete. If the wakeup_timer callback
(wakeup_timer_fn) is executing when
mwifiex_adapter_cleanup() is called, the callback
will continue to access adapter fields
(adapter->hw_status,
adapter->if_ops.card_reset, etc.) which may be
freed by mwifiex_free_adapter() called later in
the mwifiex_remove_card() path. Use
timer_delete_sync() instead to ensure any running
timer callback has completed before
returning. |
| CVE-2026-46070 |
In the Linux kernel, the
following vulnerability has been resolved:
md/raid5: validate payload size before accessing
journal metadata r5c_recovery_analyze_meta_block()
and r5l_recovery_verify_data_checksum_for_mb()
iterate over payloads in a journal metadata block
using on-disk payload size fields without
validating them against the remaining space in the
metadata block. A corrupted journal contains
payload sizes extending beyond the PAGE_SIZE
boundary can cause out-of-bounds reads when
accessing payload fields or computing offsets. Add
bounds validation for each payload type to ensure
the full payload fits within meta_size before
processing. |
| CVE-2026-46071 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
nSVM: Avoid clearing VMCB_LBR in vmcb12
svm_copy_lbrs() always marks VMCB_LBR dirty in the
destination VMCB. However, nested_svm_vmexit()
uses it to copy LBRs to vmcb12, and clearing clean
bits in vmcb12 is not architecturally defined.
Move vmcb_mark_dirty() to callers and drop it for
vmcb12. This also facilitates incoming refactoring
that does not pass the entire VMCB to
svm_copy_lbrs(). |
| CVE-2026-46072 |
In the Linux kernel, the
following vulnerability has been resolved: ntfs3:
add buffer boundary checks to run_unpack()
run_unpack() checks `run_buf < run_last` at the
top of the while loop but then reads size_size and
offset_size bytes via run_unpack_s64() without
verifying they fit within the remaining buffer. A
crafted NTFS image with truncated run data in an
MFT attribute triggers an OOB heap read of up to
15 bytes when the filesystem is mounted. Add
boundary checks before each run_unpack_s64() call
to ensure the declared field size does not exceed
the remaining buffer. Found by fuzzing with a
source-patched harness (LibAFL + QEMU). |
| CVE-2026-46073 |
In the Linux kernel, the
following vulnerability has been resolved: hwmon:
(powerz) Fix missing usb_kill_urb() on signal
interrupt
wait_for_completion_interruptible_timeout()
returns -ERESTARTSYS when interrupted. This needs
to abort the URB and return an error. No data has
been received from the device so any reads from
the transfer buffer are invalid. The original code
tests !ret, which only catches the timeout case
(0). On signal delivery (-ERESTARTSYS), !ret is
false so the function skips usb_kill_urb() and
falls through to read from the unfilled transfer
buffer. Fix by capturing the return value into a
long (matching the function return type) and
handling signal (negative) and timeout (zero)
cases with separate checks that both call
usb_kill_urb() before returning. |
| CVE-2026-46075 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
atmel-sha204a - Fix potential UAF and memory leak
in remove path Unregister the hwrng to prevent new
->read() calls and flush the Atmel I2C
workqueue before teardown to prevent a potential
UAF if a queued callback runs while the device is
being removed. Drop the early return to ensure
sysfs entries are removed and ->hwrng.priv is
freed, preventing a memory leak. |
| CVE-2026-46076 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
nSVM: Raise #UD if unhandled VMMCALL isn't
intercepted by L1 Explicitly synthesize a #UD for
VMMCALL if L2 is active, L1 does NOT want to
intercept VMMCALL,
nested_svm_l2_tlb_flush_enabled() is true, and the
hypercall is something other than one of the
supported Hyper-V hypercalls. When all of the
above conditions are met, KVM will intercept
VMMCALL but never forward it to L1, i.e. will let
L2 make hypercalls as if it were L1. The TLFS says
a whole lot of nothing about this scenario, so go
with the architectural behavior, which says that
VMMCALL #UDs if it's not intercepted.
Opportunistically do a 2-for-1 stub trade by
stub-ifying the new API instead of the helpers it
uses. The last remaining "single" stub will soon
be dropped as well. [sean: rewrite changelog and
comment, tag for stable, remove defunct
stubs] |
| CVE-2026-46077 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
atmel-tdes - fix DMA sync direction Before DMA
output is consumed by the CPU, ->dma_addr_out
must be synced with dma_sync_single_for_cpu()
instead of dma_sync_single_for_device(). Using the
wrong direction can return stale cache data on
non-coherent platforms. |
| CVE-2026-46078 |
In the Linux kernel, the
following vulnerability has been resolved: erofs:
fix the out-of-bounds nameoff handling for
trailing dirents Currently we already have
boundary-checks for nameoffs, but the trailing
dirents are special since the namelens are
calculated with strnlen() with unchecked nameoffs.
If a crafted EROFS has a trailing dirent with
nameoff >= maxsize, maxsize - nameoff can
underflow, causing strnlen() to read past the
directory block. nameoff0 should also be verified
to be a multiple of `sizeof(struct erofs_dirent)`
as well [1]. [1]
https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com |
| CVE-2026-46079 |
In the Linux kernel, the
following vulnerability has been resolved: rbd:
fix null-ptr-deref when device_add_disk() fails
do_rbd_add() publishes the device with
device_add() before calling device_add_disk(). If
device_add_disk() fails after device_add()
succeeds, the error path calls rbd_free_disk()
directly and then later falls through to
rbd_dev_device_release(), which calls
rbd_free_disk() again. This double teardown can
leave blk-mq cleanup operating on invalid state
and trigger a null-ptr-deref in
__blk_mq_free_map_and_rqs(), reached from
blk_mq_free_tag_set(). Fix this by following the
normal remove ordering: call device_del() before
rbd_dev_device_release() when device_add_disk()
fails after device_add(). That keeps the teardown
sequence consistent and avoids re-entering disk
cleanup through the wrong path. The bug was first
flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while
analyzing v6.13-rc1. The tool is still under
development and is not yet publicly available. We
reproduced the bug on v7.0 with a real Ceph
backend and a QEMU x86_64 guest booted with KASAN
and CONFIG_FAILSLAB enabled. The reproducer
confines failslab injections to the __add_disk()
range and injects fail-nth while mapping an RBD
image through /sys/bus/rbd/add_single_major. On
the unpatched kernel, fail-nth=4 reliably
triggered the fault: Oops: general protection
fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range
[0x0000000000000000-0x0000000000000007] CPU: 0
UID: 0 PID: 273 Comm: bash Not tainted
7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9,
2009), BIOS 1.15.0-1 04/01/2014 RIP:
0010:__blk_mq_free_map_and_rqs+0x8c/0x240 Code: 00
00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85
ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df
48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31
01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00 RSP:
0018:ff1100000ab0fac8 EFLAGS: 00000246 RAX:
dffffc0000000000 RBX: ff1100000c4806a0 RCX:
0000000000000000 RDX: 0000000000000002 RSI:
0000000000000000 RDI: ff1100000c4806f4 RBP:
0000000000000000 R08: 0000000000000001 R09:
ffe21c000189001b R10: ff1100000c4800df R11:
ff1100006cf37be0 R12: 0000000000000000 R13:
0000000000000000 R14: ff1100000c480700 R15:
ff1100000c480004 FS: 00007f0fbe8fe740(0000)
GS:ff110000e5851000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4:
00000000007516f0 PKRU: 55555554 Call Trace:
<TASK> blk_mq_free_tag_set+0x77/0x460
do_rbd_add+0x1446/0x2b80 ?
__pfx_do_rbd_add+0x10/0x10 ?
lock_acquire+0x18c/0x300 ?
find_held_lock+0x2b/0x80 ?
sysfs_file_kobj+0xb6/0x1b0 ?
__pfx_sysfs_kf_write+0x10/0x10
kernfs_fop_write_iter+0x2f4/0x4a0
vfs_write+0x98e/0x1000 ? expand_files+0x51f/0x850
? __pfx_vfs_write+0x10/0x10 ksys_write+0xf2/0x1d0
? __pfx_ksys_write+0x10/0x10
do_syscall_64+0x115/0x690
entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:
0033:0x7f0fbea15907 Code: 10 00 f7 d8 64 89 02 48
c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b
04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05
<48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48
89 54 24 18 48 89 74 24 RSP: 002b:00007ffe22346ea8
EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX:
ffffffffffffffda RBX: 0000000000000058 RCX:
00007f0fbea15907 RDX: 0000000000000058 RSI:
0000563ace6c0ef0 RDI: 0000000000000001 RBP:
0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09:
6b6435726d694141 R10: 5250337279762f78 R11:
0000000000000246 R12: 0000000000000058 R13:
00007f0fbeb1c780 R14: ff1100000c480700 R15:
ff1100000c480004 </TASK> With this fix
applied, rerunning the reproducer over
fail-nth=1..256 yields no KASAN reports. [
idryomov: rename err_out_device_del ->
err_out_device ] |
| CVE-2026-46080 |
In the Linux kernel, the
following vulnerability has been resolved: ocfs2:
split transactions in dio completion to avoid
credit exhaustion During ocfs2 dio operations,
JBD2 may report warnings via following call trace:
ocfs2_dio_end_io_write ocfs2_mark_extent_written
ocfs2_change_extent_flag ocfs2_split_extent
ocfs2_try_to_merge_extent
ocfs2_extend_rotate_transaction ocfs2_extend_trans
jbd2__journal_restart start_this_handle output:
JBD2: kworker/6:2 wants too many credits
credits:5450 rsv_credits:0 max:5449 To prevent
exceeding the credits limit, modify
ocfs2_dio_end_io_write() to handle extents in a
batch of transaction. Additionally, relocate
ocfs2_del_inode_from_orphan(). The orphan inode
should only be removed from the orphan list after
the extent tree update is complete. This ensures
that if a crash occurs in the middle of extent
tree updates, we won't leave stale blocks beyond
EOF. This patch also changes the logic for
updating the inode size and removing orphan,
making it similar to ext4_dio_write_end_io(). Both
operations are performed only when everything
looks good. Finally, thanks to Jans and Joseph for
providing the bug fix prototype and
suggestions. |
| CVE-2026-46082 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA
should cause a #UD when EFER.SVME is not set. Add
a check to properly inject #UD when EFER.SVME=0.
[sean: tag for stable@] |
| CVE-2026-46083 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
fix resource leaks on device setup failure Make
sure to call controller cleanup() if spi_setup()
fails while registering a device to avoid leaking
any resources allocated by setup(). |
| CVE-2026-46084 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/mana_ib: Disable RX steering on RSS QP
destroy When an RSS QP is destroyed (e.g. DPDK
exit), mana_ib_destroy_qp_rss() destroys the RX WQ
objects but does not disable vPort RX steering in
firmware. This leaves stale steering configuration
that still points to the destroyed RX objects. If
traffic continues to arrive (e.g. peer VM is still
transmitting) and the VF interface is subsequently
brought up (mana_open), the firmware may deliver
completions using stale CQ IDs from the old RX
objects. These CQ IDs can be reused by the
ethernet driver for new TX CQs, causing RX
completions to land on TX CQs: WARNING:
mana_poll_tx_cq+0x1b8/0x220 [mana] (is_sq ==
false) WARNING:
mana_gd_process_eq_events+0x209/0x290 (cq_table
lookup fails) Fix this by disabling vPort RX
steering before destroying RX WQ objects. Note
that mana_fence_rqs() cannot be used here because
the fence completion is delivered on the CQ, which
is polled by user-mode (e.g. DPDK) and not visible
to the kernel driver. Refactor the disable logic
into a shared mana_disable_vport_rx() in mana_en,
exported for use by mana_ib, replacing the
duplicate code. The ethernet driver's
mana_dealloc_queues() is also updated to call this
common function. |
| CVE-2026-46086 |
In the Linux kernel, the
following vulnerability has been resolved: net:
bridge: use a stable FDB dst snapshot in RCU
readers Local FDB entries can be rewritten in
place by `fdb_delete_local()`, which updates
`f->dst` to another port or to `NULL` while
keeping the entry alive. Several bridge RCU
readers inspect `f->dst`, including
`br_fdb_fillbuf()` through the `brforward_read()`
sysfs path. These readers currently load
`f->dst` multiple times and can therefore
observe inconsistent values across the check and
later dereference. In `br_fdb_fillbuf()`, this
means a concurrent local-FDB update can change
`f->dst` after the NULL check and before the
`port_no` dereference, leading to a
NULL-ptr-deref. Fix this by taking a single
`READ_ONCE()` snapshot of `f->dst` in each
affected RCU reader and using that snapshot for
the rest of the access sequence. Also publish the
in-place `f->dst` updates in
`fdb_delete_local()` with `WRITE_ONCE()` so the
readers and writer use matching access
patterns. |
| CVE-2026-46088 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
control: Validate buf_len before strnlen() in
snd_ctl_elem_init_enum_names()
snd_ctl_elem_init_enum_names() advances pointer p
through the names buffer while decrementing
buf_len. If buf_len reaches zero but items remain,
the next iteration calls strnlen(p, 0). While
strnlen(p, 0) returns 0 and would hit the existing
name_len == 0 error path, CONFIG_FORTIFY_SOURCE's
fortified strnlen() first checks maxlen against
__builtin_dynamic_object_size(). When Clang loses
track of p's object size inside the loop, this
triggers a BRK exception panic before the return
value is examined. Add a buf_len == 0 guard at the
loop entry to prevent calling fortified strnlen()
on an exhausted buffer. Found by kernel fuzz
testing through Xiaomi Smartphone. |
| CVE-2026-46089 |
In the Linux kernel, the
following vulnerability has been resolved: zram:
do not forget to endio for partial discard
requests As reported by Qu Wenruo and Avinesh
Kumar, the following getconf PAGESIZE 65536
blkdiscard -p 4k /dev/zram0 takes literally
forever to complete. zram doesn't support partial
discards and just returns immediately w/o doing
any discard work in such cases. The problem is
that we forget to endio on our way out, so
blkdiscard sleeps forever in submit_bio_wait().
Fix this by jumping to end_bio label, which does
bio_endio(). |
| CVE-2026-46090 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
aloop: Fix peer runtime UAF during format-change
stop loopback_check_format() may stop the capture
side when playback starts with parameters that no
longer match a running capture stream. Commit
826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM
trigger") moved the peer lookup under
cable->lock, but the actual snd_pcm_stop()
still runs after dropping that lock. A concurrent
close can clear the capture entry from
cable->streams[] and detach or free its runtime
while the playback trigger path still holds a
stale peer substream pointer. Keep a per-cable
count of in-flight peer stops before dropping
cable->lock, and make free_cable() wait for
those stops before detaching the runtime. This
preserves the existing behavior while making the
peer runtime lifetime explicit. |
| CVE-2026-46091 |
In the Linux kernel, the
following vulnerability has been resolved: media:
rc: igorplugusb: heed coherency rules In a control
request, the USB request structure can be subject
to DMA on some HCs. Hence it must obey the rules
for DMA coherency. Allocate it separately. |
| CVE-2026-46092 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
rtw88: check for PCI upstream bridge existence
pci_upstream_bridge() returns NULL if the device
is on a root bus. If 8821CE is installed in the
system with such a PCI topology, the probing
routine will crash. This has probably been
unnoticed as 8821CE is mostly supplied in laptops
where there is a PCI-to-PCI bridge located
upstream from the device. However the card might
be installed on a system with different
configuration. Check if the bridge does exist for
the specific workaround to be applied. Found by
Linux Verification Center (linuxtesting.org) with
Svace static analysis tool. |
| CVE-2026-46094 |
In the Linux kernel, the
following vulnerability has been resolved: ext4:
fix bounds check in check_xattrs() to prevent
out-of-bounds access The bounds check for the next
xattr entry in check_xattrs() uses (void *)next
>= end, which allows next to point within
sizeof(u32) bytes of end. On the next loop
iteration, IS_LAST_ENTRY() reads 4 bytes via
*(__u32 *)(entry), which can overrun the valid
xattr region. For example, if next lands at end -
1, the check passes since next < end, but
IS_LAST_ENTRY() reads 4 bytes starting at end - 1,
accessing 3 bytes beyond the valid region. Fix
this by changing the check to (void *)next +
sizeof(u32) > end, ensuring there is always
enough space for the IS_LAST_ENTRY() read on the
subsequent iteration. |
| CVE-2026-46098 |
In the Linux kernel, the
following vulnerability has been resolved: net:
caif: clear client service pointer on teardown
`caif_connect()` can tear down an existing client
after remote shutdown by calling
`caif_disconnect_client()` followed by
`caif_free_client()`. `caif_free_client()`
releases the service layer referenced by
`adap_layer->dn`, but leaves that pointer
stale. When the socket is later destroyed,
`caif_sock_destructor()` calls
`caif_free_client()` again and dereferences the
freed service pointer. Clear the client/service
links before releasing the service object so
repeated teardown becomes harmless. |
| CVE-2026-46099 |
In the Linux kernel, the
following vulnerability has been resolved: net:
ipv6: fix NOREF dst use in seg6 and rpl lwtunnels
seg6_input_core() and rpl_input() call
ip6_route_input() which sets a NOREF dst on the
skb, then pass it to dst_cache_set_ip6() invoking
dst_hold() unconditionally. On PREEMPT_RT,
ksoftirqd is preemptible and a higher-priority
task can release the underlying pcpu_rt between
the lookup and the caching through a concurrent
FIB lookup on a shared nexthop. Simplified race
sequence: ksoftirqd/X higher-prio task (same CPU
X) ----------- --------------------------------
seg6_input_core(,skb)/rpl_input(skb)
dst_cache_get() -> miss ip6_route_input(skb)
-> ip6_pol_route(,skb,flags)
[RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup
resolves fib6_nh [nhid=N route] ->
rt6_make_pcpu_route() [creates pcpu_rt,
refcount=1] pcpu_rt->sernum = fib6_sernum
[fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu,
NULL, pcpu_rt) [slot was empty, store succeeds]
-> skb_dst_set_noref(skb, dst) [dst is pcpu_rt,
refcount still 1] rt_genid_bump_ipv6() -> bumps
fib6_sernum [fib6_sernum from W to Z]
ip6_route_output() -> ip6_pol_route() -> FIB
lookup resolves fib6_nh [nhid=N] ->
rt6_get_pcpu_route() pcpu_rt->sernum !=
fib6_sernum [W <> Z, stale] -> prev =
xchg(rt6i_pcpu, NULL) -> dst_release(prev)
[prev is pcpu_rt, refcount 1->0, dead] dst =
skb_dst(skb) [dst is the dead pcpu_rt]
dst_cache_set_ip6(dst) -> dst_hold() on dead
dst -> WARN / use-after-free For the race to
occur, ksoftirqd must be preemptible (PREEMPT_RT
without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent
task must be able to release the pcpu_rt. Shared
nexthop objects provide such a path, as two routes
pointing to the same nhid share the same fib6_nh
and its rt6i_pcpu entry. Fix seg6_input_core() and
rpl_input() by calling skb_dst_force() after
ip6_route_input() to force the NOREF dst into a
refcounted one before caching. The output path is
not affected as ip6_route_output() already returns
a refcounted dst. |
| CVE-2026-46101 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: reject zero shift in nft_bitwise Reject
zero shift operands for nft_bitwise left and right
shift expressions during initialization. The carry
propagation logic computes the carry from the
adjacent 32-bit word using BITS_PER_TYPE(u32) -
shift. A zero shift operand turns this into a
32-bit shift, which is undefined behaviour. Reject
zero shift operands in the control plane,
alongside the existing check for values greater
than or equal to 32, so malformed rules never
reach the packet path. |
| CVE-2026-46102 |
In the Linux kernel, the
following vulnerability has been resolved: net:
strparser: fix skb_head leak in strp_abort_strp()
When the stream parser is aborted, for example
after a message assembly timeout, it can still
hold a reference to a partially assembled message
in strp->skb_head. That skb is not released in
strp_abort_strp(), which leaks the partially
assembled message and can be triggered repeatedly
to exhaust memory. Fix this by freeing
strp->skb_head and resetting the parser state
in the abort path. Leave strp_stop() unchanged so
final cleanup still happens in strp_done() after
the work and timer have been synchronized. |
| CVE-2026-46103 |
In the Linux kernel, the
following vulnerability has been resolved: can:
ucan: fix devres lifetime USB drivers bind to USB
interfaces and any device managed resources should
have their lifetime tied to the interface rather
than parent USB device. This avoids issues like
memory leaks when drivers are unbound without
their devices being physically disconnected (e.g.
on probe deferral or configuration changes). Fix
the control message buffer lifetime so that it is
released on driver unbind. |
| CVE-2026-46106 |
In the Linux kernel, the
following vulnerability has been resolved:
eventfs: Hold eventfs_mutex and SRCU when remount
walks events Commit 340f0c7067a9 ("eventfs: Update
all the eventfs_inodes from the events
descriptor") had eventfs_set_attrs() recurse
through ei->children on remount. The walk only
holds the rcu_read_lock() taken by
tracefs_apply_options() over tracefs_inodes, which
is wrong: - list_for_each_entry over
ei->children races with the list_del_rcu() in
eventfs_remove_rec() -- LIST_POISON1 deref, same
shape as d2603279c7d6. - eventfs_inodes are freed
via call_srcu(&eventfs_srcu, ...).
rcu_read_lock() does not extend an SRCU grace
period, so ti->private can be reclaimed under
the walk. - The writes to ei->attr race with
eventfs_set_attr(), which holds eventfs_mutex.
Reproducer: while :; do mount -o
remount,uid=$((RANDOM%1000)) /sys/kernel/tracing;
done & while :; do echo "p:kp submit_bio" >
/sys/kernel/tracing/kprobe_events echo >
/sys/kernel/tracing/kprobe_events done Wrap the
events portion of tracefs_apply_options() in
eventfs_remount_lock()/_unlock() that take
eventfs_mutex and
srcu_read_lock(&eventfs_srcu).
eventfs_set_attrs() doesn't sleep so the nested
rcu_read_lock() is fine; lockdep_assert_held()
pins the contract. Comment in tracefs_drop_inode()
said "RCU cycle" -- it is SRCU. |
| CVE-2026-46107 |
In the Linux kernel, the
following vulnerability has been resolved:
dm-thin: fix metadata refcount underflow There's a
bug in dm-thin in the function rebalance_children.
If the internal btree node has one entry, the code
tries to copy all btree entries from the node's
child to the node itself and then decrement the
child's reference count. If the child node is
shared (it has reference count > 1), we won't
free it, so there would be two pointers to each of
the grandchildren nodes. But the reference counts
of the grandchildren is not increased, thus the
reference count doesn't match the number of
pointers that point to the grandchildren. This
results in "device mapper: space map common:
unable to decrement block" errors. Fix this bug by
incrementing reference counts on the grandchildren
if the btree node is shared. |
| CVE-2026-46108 |
In the Linux kernel, the
following vulnerability has been resolved:
ipmi:si: Return state to normal if message
allocation fails There were places where nothing
would get started if a message allocation failed,
so the driver needs to return to normal
state. |
| CVE-2026-46110 |
In the Linux kernel, the
following vulnerability has been resolved: net:
stmmac: Prevent NULL deref when RX memory
exhausted The CPU receives frames from the MAC
through conventional DMA: the CPU allocates
buffers for the MAC, then the MAC fills them and
returns ownership to the CPU. For each hardware RX
queue, the CPU and MAC coordinate through a shared
ring array of DMA descriptors: one descriptor per
DMA buffer. Each descriptor includes the buffer's
physical address and a status flag ("OWN")
indicating which side owns the buffer: OWN=0 for
CPU, OWN=1 for MAC. The CPU is only allowed to set
the flag and the MAC is only allowed to clear it,
and both must move through the ring in sequence:
thus the ring is used for both "submissions" and
"completions." In the stmmac driver, stmmac_rx()
bookmarks its position in the ring with the
`cur_rx` index. The main receive loop in that
function checks for rx_descs[cur_rx].own=0, gives
the corresponding buffer to the network stack
(NULLing the pointer), and increments `cur_rx`
modulo the ring size. After the loop exits,
stmmac_rx_refill(), which bookmarks its position
with `dirty_rx`, allocates fresh buffers and
rearms the descriptors (setting OWN=1). If it
fails any allocation, it simply stops early
(leaving OWN=0) and will retry where it left off
when next called. This means descriptors have a
three-stage lifecycle (terms my own): - `empty`
(OWN=1, buffer valid) - `full` (OWN=0, buffer
valid and populated) - `dirty` (OWN=0, buffer
NULL) But because stmmac_rx() only checks OWN, it
confuses `full`/`dirty`. In the past (see
'Fixes:'), there was a bug where the loop could
cycle `cur_rx` all the way back to the first
descriptor it dirtied, resulting in a NULL
dereference when mistaken for `full`. The
aforementioned commit resolved that *specific*
failure by capping the loop's iteration limit at
`dma_rx_size - 1`, but this is only a partial fix:
if the previous stmmac_rx_refill() didn't
complete, then there are leftover `dirty`
descriptors that the loop might encounter without
needing to cycle fully around. The current code
therefore panics (see 'Closes:') when
stmmac_rx_refill() is memory-starved long enough
for `cur_rx` to catch up to `dirty_rx`. Fix this
by explicitly checking, before advancing `cur_rx`,
if the next entry is dirty; exit the loop if so.
This prevents processing of the final, used
descriptor until stmmac_rx_refill() succeeds, but
fully prevents the `cur_rx == dirty_rx` ambiguity
as the previous bugfix intended: so remove the
clamp as well. Since stmmac_rx_zc() is a
copy-paste-and-tweak of stmmac_rx() and the code
structure is identical, any fix to stmmac_rx()
will also need a corresponding fix for
stmmac_rx_zc(). Therefore, apply the same check
there. In stmmac_rx() (not stmmac_rx_zc()), a
related bug remains: after the MAC sets OWN=0 on
the final descriptor, it will be unable to send
any further DMA-complete IRQs until it's given
more `empty` descriptors. Currently, the driver
simply *hopes* that the next stmmac_rx_refill()
succeeds, risking an indefinite stall of the
receive process if not. But this is not a
regression, so it can be addressed in a future
change. |
| CVE-2026-46111 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: hci_conn: fix potential UAF in
create_big_sync Add hci_conn_valid() check in
create_big_sync() to detect stale connections
before proceeding with BIG creation. Handle the
resulting -ECANCELED in create_big_complete() and
re-validate the connection under hci_dev_lock()
before dereferencing, matching the pattern used by
create_le_conn_complete() and
create_pa_complete(). Keep the hci_conn object
alive across the async boundary by taking a
reference via hci_conn_get() when queueing
create_big_sync(), and dropping it in the
completion callback. The refcount and the lock are
complementary: the refcount keeps the object
allocated, while hci_dev_lock() serializes
hci_conn_hash_del()'s list_del_rcu() on
hdev->conn_hash, as required by hci_conn_del().
hci_conn_put() is called outside hci_dev_unlock()
so the final put (which resolves to kfree() via
bt_link_release) does not run under hdev->lock,
though the release path would be safe either way.
Without this, create_big_complete() would
unconditionally dereference the conn pointer on
error, causing a use-after-free via
hci_connect_cfm() and hci_conn_del(). |
| CVE-2026-46112 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/hns: Fix unlocked call to
hns_roce_qp_remove() Sashiko points out that
hns_roce_qp_remove() requires the caller to hold
locks. The error flow in
hns_roce_create_qp_common() doesn't hold those
locks for the error unwind so it risks corrupting
memory. Grab the same locks the other two callers
use. |
| CVE-2026-46113 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
x86: Fix shadow paging use-after-free due to
unexpected GFN The shadow MMU computes GFNs for
direct shadow pages using sp->gfn plus the SPTE
index. This assumption breaks for shadow paging if
the guest page tables are modified between VM
entries (similar to commit aad885e77496, "KVM:
x86/mmu: Drop/zap existing present SPTE even when
creating an MMIO SPTE", 2026-03-27). The flow is
as follows: - a PDE is installed for a 2MB
mapping, and a page in that area is accessed. KVM
creates a kvm_mmu_page consisting of 512 4KB
pages; the kvm_mmu_page is marked by FNAME(fetch)
as direct-mapped because the guest's mapping is a
huge page (and thus contiguous). - the PDE mapping
is changed from outside the guest. - the guest
accesses another page in the same 2MB area. KVM
installs a new leaf SPTE and rmap entry; the SPTE
uses the "correct" GFN (i.e. based on the new
mapping, as changed in the previous step) but that
GFN is outside of the [sp->gfn, sp->gfn +
511] range; therefore the rmap entry cannot be
found and removed when the kvm_mmu_page is zapped.
- the memslot that covers the first 2MB mapping is
deleted, and the kvm_mmu_page for the now-invalid
GPA is zapped. However, rmap_remove() only looks
at the [sp->gfn, sp->gfn + 511] range
established in step 1, and fails to find the rmap
entry that was recorded by step 3. - any operation
that causes an rmap walk for the same page
accessed by step 3 then walks a stale rmap and
dereferences a freed kvm_mmu_page. This includes
dirty logging or MMU notifier invalidations (e.g.,
from MADV_DONTNEED). The underlying issue is that
KVM's walking of shadow PTEs assumes that if a
SPTE is present when KVM wants to install a
non-leaf SPTE, then the existing kvm_mmu_page must
be for the correct gfn. Because the only way for
the gfn to be wrong is if KVM messed up and failed
to zap a SPTE... which shouldn't happen, but
*actually* only happens in response to a guest
write. That bug dates back literally forever, as
even the first version of KVM assumes that the GFN
matches and walks into the "wrong" shadow page.
However, that was only an imprecision until
2032a93d66fa ("KVM: MMU: Don't allocate gfns page
for direct mmu pages") came along. Fix it by
checking for a target gfn mismatch and zapping the
existing SPTE. That way the old SP and rmap
entries are gone, KVM installs the rmap in the
right location, and everyone is happy. |
| CVE-2026-46114 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads
atomic_write_reply() at
drivers/infiniband/sw/rxe/rxe_resp.c
unconditionally dereferences 8 bytes at
payload_addr(pkt): value = *(u64
*)payload_addr(pkt); check_rkey() previously
accepted an ATOMIC_WRITE request with pktlen ==
resid == 0 because the length validation only
compared pktlen against resid. A remote initiator
that sets the RETH length to 0 therefore reaches
atomic_write_reply() with a zero-byte logical
payload, and the responder reads sizeof(u64) bytes
from past the logical end of the packet into
skb->head tailroom, then writes those 8 bytes
into the attacker's MR via
rxe_mr_do_atomic_write(). That is a remote
disclosure of 4 bytes of kernel tailroom per probe
(the other 4 bytes are the packet's own trailing
ICRC). IBA oA19-28 defines ATOMIC_WRITE as exactly
8 bytes. Anything else is protocol-invalid. Hoist
a strict length check into check_rkey() so the
responder never reaches the unchecked dereference,
and keep the existing WRITE-family length logic
for the normal RDMA WRITE path. Reproduced on
mainline with an unmodified rxe driver: a
sustained zero-length ATOMIC_WRITE probe
repeatedly leaks adjacent skb head-buffer bytes
into the attacker's MR, including recognisable
kernel strings and partial kernel-direct-map
pointer words. With this patch applied the
responder rejects the PDU and the MR stays
all-zero. |
| CVE-2026-46115 |
In the Linux kernel, the
following vulnerability has been resolved: block:
add pgmap check to biovec_phys_mergeable
biovec_phys_mergeable() is used by the request
merge, DMA mapping, and integrity merge paths to
decide if two physically contiguous bvec segments
can be coalesced into one. It currently has no
check for whether the segments belong to different
dev_pagemaps. When zone device memory is
registered in multiple chunks, each chunk gets its
own dev_pagemap. A single bio can legitimately
contain bvecs from different pgmaps --
iov_iter_extract_bvecs() breaks at pgmap
boundaries but the outer loop in
bio_iov_iter_get_pages() continues filling the
same bio. If such bvecs are physically contiguous,
biovec_phys_mergeable() will coalesce them, making
it impossible to recover the correct pgmap for the
merged segment via page_pgmap(). Add a
zone_device_pages_have_same_pgmap() check to
prevent merging bvec segments that span different
pgmaps. |
| CVE-2026-46116 |
In the Linux kernel, the
following vulnerability has been resolved: xfrm:
defensively unhash xfrm_state lists in
__xfrm_state_delete KASAN reproduces a
slab-use-after-free in __xfrm_state_delete()'s
hlist_del_rcu calls under syzkaller load on
linux-6.12.y stable (reproduced on 6.12.47, also
reachable via the same code path on
torvalds/master and on the ipsec tree). Nine
unique signatures cluster in the xfrm_state
lifecycle, the load-bearing one being: BUG: KASAN:
slab-use-after-free in __hlist_del
include/linux/list.h:990 [inline] BUG: KASAN:
slab-use-after-free in hlist_del_rcu
include/linux/rculist.h:516 [inline] BUG: KASAN:
slab-use-after-free in __xfrm_state_delete
net/xfrm/xfrm_state.c Write of size 8 at addr
ffff8881198bcb70 by task kworker/u8:9/435
Workqueue: netns cleanup_net Call Trace:
__hlist_del / hlist_del_rcu __xfrm_state_delete
xfrm_state_delete xfrm_state_flush xfrm_state_fini
ops_exit_list cleanup_net The other observed
signatures hit the same slab object from
__xfrm_state_lookup, xfrm_alloc_spi,
__xfrm_state_insert and an OOB write variant of
__xfrm_state_delete, all on the byseq/byspi hash
chains. __xfrm_state_delete() guards its byseq and
byspi unhashes with value-based predicates: if
(x->km.seq) hlist_del_rcu(&x->byseq); if
(x->id.spi) hlist_del_rcu(&x->byspi);
while everywhere else in the file (e.g.
state_cache, state_cache_input) the safer
hlist_unhashed() check is used. xfrm_alloc_spi()
sets x->id.spi = newspi inside xfrm_state_lock
and then immediately inserts into byspi, but a
path that observes x->id.spi != 0 outside of
xfrm_state_lock can still skip-or-hit the byspi
unhash inconsistently with whether x is actually
on the list. The same holds for x->km.seq
versus byseq, and the bydst/bysrc unhashes have no
predicate at all, so a second
__xfrm_state_delete() on the same object writes
through LIST_POISON pprev. The defensive change
here: - Use hlist_del_init_rcu() instead of
hlist_del_rcu() on bydst, bysrc, byseq and byspi
so a second deletion is a no-op rather than a
write through LIST_POISON pprev. The byseq/byspi
nodes are already initialised in
xfrm_state_alloc(). - Test hlist_unhashed() rather
than the value predicate for byseq/byspi, so the
unhash decision tracks list state rather than
mutable scalar fields. Empirical verification:
applied this patch on top of v6.12.47, rebuilt,
and re-ran the same syzkaller harness for 1h16m on
a previously-crashy configuration that produced
~100 hits each of slab-use-after-free Read in
xfrm_alloc_spi / Read in __xfrm_state_lookup /
Write in __xfrm_state_delete. After the patch,
7.1M execs across 32 VMs at ~1550 exec/sec
produced zero xfrm_state UAF/OOB hits.
/proc/slabinfo confirms the xfrm_state slab is
actively allocated and freed during the run (~143
KiB resident), so the fuzzer is still exercising
those code paths -- they just no longer crash.
Reproduction: - Linux 6.12.47 x86_64 +
KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @
746545b8b1e4c3a128db8652b340d3df90ce61db - 32
QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal -
9 unique signatures collected in ~9h, all within
xfrm_state lifecycle |
| CVE-2026-46117 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/mana: Remove user triggerable WARN_ON() in
mana_ib_create_qp_rss() Sashiko points out that
the user can specify WQs sharing the same CQ as a
part of the uAPI and this will trigger the
WARN_ON() then go on to corrupt the kernel. Just
reject it outright and fail the QP
creation. |
| CVE-2026-46118 |
In the Linux kernel, the
following vulnerability has been resolved:
pseries/papr-hvpipe: Fix null ptr deref in
papr_hvpipe_dev_create_handle() commit
6d3789d347a7 ("papr-hvpipe: convert
papr_hvpipe_dev_create_handle() to FD_PREPARE()"),
changed the create handle to FD_PREPARE(), but it
caused kernel null-ptr-deref because after call to
retain_and_null_ptr(src_info), src_info is re-used
for adding it to the global list. Getting the
following kernel panic in
papr_hvpipe_dev_create_handle() when trying to add
src_info to the list. Kernel attempted to write
user page (0) - exploit attempt? (uid: 0) BUG:
Kernel NULL pointer dereference on write at
0x00000000 Faulting instruction address:
0xc0000000001b44a0 Oops: Kernel access of bad
area, sig: 11 [#1] ... Call Trace:
papr_hvpipe_dev_ioctl+0x1f4/0x48c (unreliable)
sys_ioctl+0x528/0x1064
system_call_exception+0x128/0x360
system_call_vectored_common+0x15c/0x2ec Now, the
error handling with FD_PREPARE's file cleanup and
__free(kfree) auto cleanup is getting too
convoluted. This is mainly because we need to
ensure only 1 user get the srcID handle. To
simplify this, we allocate prepare the src_info in
the beginning and add it to the global list under
a spinlock after checking that no duplicates
exist. This simplify the error handling where if
the FD_ADD fails, we can simply remove the
src_info from the list and consume any pending msg
in hvpipe to be cleared, after src_info became
visible in the global list. |
| CVE-2026-46119 |
In the Linux kernel, the
following vulnerability has been resolved:
libceph: Fix slab-out-of-bounds access in auth
message processing If a (potentially corrupted)
message of type CEPH_MSG_AUTH_REPLY contains a
positive value in its result field, it is treated
as an error code by ceph_handle_auth_reply() and
returned to handle_auth_reply(). Thereafter, an
attempt is made to send the preallocated message
of type CEPH_MSG_AUTH, where the returned value is
interpreted as the size of the front segment to
send. If the result value in the message is
greater than the size of the memory buffer
allocated for the front segment, an out-of-bounds
access occurs, and the content of the memory
region beyond this buffer is sent out. This patch
fixes the issue by treating only negative values
in the result field as errors. Positive values are
therefore treated as success in the same way as a
zero value. Additionally, a BUG_ON is added to
__send_prepared_auth_request() comparing the len
parameter to front_alloc_len to prevent sending
the message if it exceeds the bounds of the
allocation and to make it easier to catch any
logic flaws leading to this. |
| CVE-2026-46120 |
In the Linux kernel, the
following vulnerability has been resolved:
ip6_gre: Use cached t->net in
ip6erspan_changelink(). After commit 5e72ce3e3980
("net: ipv6: Use link netns in newlink() of
rtnl_link_ops"), ip6erspan_newlink() correctly
resolves the per-netns ip6gre hash via link_net.
ip6erspan_changelink() was not converted in that
series and still uses dev_net(dev), which diverges
from the device's creation netns after
IFLA_NET_NS_FD migration. This re-inserts the
tunnel into the wrong per-netns hash. The original
netns keeps a stale entry. When that netns is
later destroyed, ip6gre_exit_rtnl_net() walks the
stale entry, producing a slab-use-after-free
reported by KASAN, followed by a kernel BUG at
net/core/dev.c (LIST_POISON1) in
unregister_netdevice_many_notify(). Reachable from
an unprivileged user namespace (unshare --user
--map-root-user --net). ip6gre_changelink()
earlier in the same file already uses the cached
t->net; only ip6erspan_changelink() has the
wrong shape. |
| CVE-2026-46121 |
In the Linux kernel, the
following vulnerability has been resolved:
mm/damon/sysfs-schemes: protect memcg_path kfree()
with damon_sysfs_lock Patch series
"mm/damon/sysfs-schemes: fix use-after-free for
[memcg_]path". Reads of 'memcg_path' and 'path'
files in DAMON sysfs interface could race with
their writes, results in use-after-free. Fix
those. This patch (of 2):
damon_sysfs_scheme_filter->mmecg_path can be
read and written by users, via DAMON sysfs
memcg_path file. It can also be indirectly read,
for the parameters {on,off}line committing to
DAMON. The reads for parameters committing are
protected by damon_sysfs_lock to avoid the sysfs
files being destroyed while any of the parameters
are being read. But the user-driven direct reads
and writes are not protected by any lock, while
the write is deallocating the memcg_path-pointing
buffer. As a result, the readers could read the
already freed buffer (user-after-free). Note that
the user-reads don't race when the same open file
is used by the writer, due to kernfs's open file
locking. Nonetheless, doing the reads and writes
with separate open files would be common. Fix it
by protecting both the user-direct reads and
writes with damon_sysfs_lock. |
| CVE-2026-46122 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
b43: enforce bounds check on firmware key index in
b43_rx() The firmware-controlled key index in
b43_rx() can exceed the dev->key[] array size
(58 entries). The existing B43_WARN_ON is
non-enforcing in production builds, allowing an
out-of-bounds read. Make the B43_WARN_ON check
enforcing by dropping the frame when the firmware
returns an invalid key index. |
| CVE-2026-46123 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: virtio_bt: clamp rx length before
skb_put virtbt_rx_work() calls skb_put(skb, len)
where len comes directly from virtqueue_get_buf()
with no validation against the buffer we posted to
the device. The RX skb is allocated in
virtbt_add_inbuf() and exposed to virtio as
exactly 1000 bytes via sg_init_one(). Checking len
against skb_tailroom(skb) is not sufficient
because alloc_skb() can leave more tailroom than
the 1000 bytes actually handed to the device. A
malicious or buggy backend can therefore report
used.len between 1001 and skb_tailroom(skb),
causing skb_put() to include uninitialized kernel
heap bytes that were never written by the device.
The same path also accepts len == 0, in which case
skb_put(skb, 0) leaves the skb empty but
virtbt_rx_handle() still reads the pkt_type byte
from skb->data, consuming uninitialized memory.
Define VIRTBT_RX_BUF_SIZE once and reuse it in
alloc_skb() and sg_init_one(), and gate
virtbt_rx_work() on that same constant so the
bound checked matches the buffer actually exposed
to the device. Reject used.len == 0 in the same
gate so an empty completion can no longer reach
virtbt_rx_handle(). Use bt_dev_err_ratelimited()
because the length value comes from an untrusted
backend that can otherwise flood the kernel log.
Same class of bug as commit c04db81cd028 ("net/9p:
Fix buffer overflow in USB transport layer"),
which hardened the USB 9p transport against
unchecked device-reported length. |
| CVE-2026-46124 |
In the Linux kernel, the
following vulnerability has been resolved: isofs:
validate block number from NFS file handle in
isofs_export_iget isofs_fh_to_dentry() and
isofs_fh_to_parent() pass an attacker- controlled
block number (ifid->block or
ifid->parent_block) from the NFS file handle to
isofs_export_iget(), which only rejects block == 0
before calling isofs_iget() and ultimately
sb_bread(). A crafted file handle with fh_len
sufficient to pass the check added by commit
0405d4b63d08 ("isofs: Prevent the use of too small
fid") can still drive the server to read any
in-range block on the backing device as if it were
an iso_directory_record. That earlier fix was
assigned CVE-2025-37780. sb_bread() on an
out-of-range block returns NULL cleanly via the
EIO path, so there is no memory-safety violation.
For in-range reads of adjacent-partition data on
the same block device, the unrelated bytes end up
in iso_inode_info fields that reach the NFS client
as dentry metadata. The deployment surface (isofs
exported over NFS from loop-mounted images) is
narrow and requires an authenticated NFS peer, but
the malformed-file-handle class is reportable as
hardening next to the existing CVE-2025-37780 fix.
Reject block >= ISOFS_SB(sb)->s_nzones in
isofs_export_iget() so the check covers both
isofs_fh_to_dentry() and isofs_fh_to_parent() call
sites with a single line. |
| CVE-2026-46125 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
mac80211: remove station if connection prep fails
If connection preparation fails for MLO
connections, then the interface is completely
reset to non-MLD. In this case, we must not keep
the station since it's related to the link of the
vif being removed. Delete an existing station. Any
"new_sta" is already being removed, so that
doesn't need changes. This fixes a
use-after-free/double-free in debugfs if that's
enabled, because a vif going from MLD (and to MLD,
but that's not relevant here) recreates its entire
debugfs. |
| CVE-2026-46126 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/mana: Fix mana_destroy_wq_obj() cleanup in
mana_ib_create_qp_rss() Sashiko points out there
are two bugs here in the error unwind flow, both
related to how the WQ table is unwound. First
there is a double i-- on the first failure path
due to the while loop having a i--, remove it.
Second if mana_ib_install_cq_cb() fails then
mana_create_wq_obj() is not undone due to the
above i--. |
| CVE-2026-46127 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/ocrdma: Don't NULL deref uctx on errors in
ocrdma_copy_pd_uresp() Sashiko points out that
pd->uctx isn't initialized until late in the
function so all these error flow references are
NULL and will crash. Use the uctx that isn't
NULL. |
| CVE-2026-46128 |
In the Linux kernel, the
following vulnerability has been resolved: ipmi:
Check event message buffer response for bad data
The event message buffer response data size got
checked later when processing, but check it right
after the response comes back. It appears some
BMCs may return an empty message instead of an
error when fetching events. There are apparently
some new BMCs that make this error, so we need to
compensate. |
| CVE-2026-46129 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
fix double free in create_space_info() error path
When kobject_init_and_add() fails, the call chain
is: create_space_info() ->
btrfs_sysfs_add_space_info_type() ->
kobject_init_and_add() -> failure ->
kobject_put(&space_info->kobj) ->
space_info_release() -> kfree(space_info) Then
control returns to create_space_info():
btrfs_sysfs_add_space_info_type() returns error
-> goto out_free -> kfree(space_info) This
causes a double free. Keep the direct
kfree(space_info) for the earlier failure path,
but after btrfs_sysfs_add_space_info_type() has
called kobject_put(), let the kobject release
callback handle the cleanup. |
| CVE-2026-46130 |
In the Linux kernel, the
following vulnerability has been resolved:
dm-verity-fec: fix reading parity bytes split
across blocks (take 3) fec_decode_bufs() assumes
that the parity bytes of the first RS codeword it
decodes are never split across parity blocks. This
assumption is false. Consider
v->fec->block_size == 4096 &&
v->fec->roots == 17 && fio->nbufs
== 1, for example. In that case, each call to
fec_decode_bufs() consumes v->fec->roots *
(fio->nbufs << DM_VERITY_FEC_BUF_RS_BITS)
= 272 parity bytes. Considering that the parity
data for each message block starts on a block
boundary, the byte alignment in the parity data
will iterate through 272*i mod 4096 until the 3
parity blocks have been consumed. On the 16th call
(i=15), the alignment will be 4080 bytes into the
first block. Only 16 bytes remain in that block,
but 17 parity bytes will be needed. The code reads
out-of-bounds from the parity block buffer.
Fortunately this doesn't normally happen, since it
can occur only for certain non-default values of
fec_roots *and* when the maximum number of buffers
couldn't be allocated due to low memory. For
example with block_size=4096 only the following
cases are affected: fec_roots=17: nbufs in [1, 3,
5, 15] fec_roots=19: nbufs in [1, 229]
fec_roots=21: nbufs in [1, 3, 5, 13, 15, 39, 65,
195] fec_roots=23: nbufs in [1, 89] Regardless,
fix it by refactoring how the parity blocks are
read. |
| CVE-2026-46131 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
x86: check for nEPT/nNPT in slow flush hypercalls
Checking is_guest_mode(vcpu) is incorrect, because
translate_nested_gpa() is only valid if an L2
guest is running *with nested EPT/NPT enabled*.
Instead use the same condition as
translate_nested_gpa() itself. |
| CVE-2026-46132 |
In the Linux kernel, the
following vulnerability has been resolved: net:
rtnetlink: zero ifla_vf_broadcast to avoid stack
infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo()
declares struct ifla_vf_broadcast on the stack
without initialisation: struct ifla_vf_broadcast
vf_broadcast; The struct contains a single fixed
32-byte field: /* include/uapi/linux/if_link.h */
struct ifla_vf_broadcast { __u8 broadcast[32]; };
The function then copies dev->broadcast into it
using dev->addr_len as the length:
memcpy(vf_broadcast.broadcast, dev->broadcast,
dev->addr_len); On Ethernet devices (the
overwhelming majority of SR-IOV NICs)
dev->addr_len is 6, so only the first 6 bytes
of broadcast[] are written. The remaining 26 bytes
retain whatever was previously on the kernel
stack. The full struct is then handed to userspace
via: nla_put(skb, IFLA_VF_BROADCAST,
sizeof(vf_broadcast), &vf_broadcast) leaking
up to 26 bytes of uninitialised kernel stack per
VF per RTM_GETLINK request, repeatable. The other
vf_* structs in the same function are explicitly
zeroed for exactly this reason - see the memset()
calls for ivi, vf_vlan_info, node_guid and
port_guid a few lines above. vf_broadcast was
simply missed when it was added. Reachability: any
unprivileged local process can open AF_NETLINK /
NETLINK_ROUTE without capabilities and send
RTM_GETLINK with an IFLA_EXT_MASK attribute
carrying RTEXT_FILTER_VF. The kernel walks each VF
and emits IFLA_VF_BROADCAST, leaking 26 bytes of
stack per VF per request. Stack residue at this
call site can include return addresses and
transient sensitive data; KASAN with stack
instrumentation, or KMSAN, will flag the nla_put()
when reproduced. Zero the on-stack struct before
the partial memcpy, matching the existing pattern
used for the other vf_* structs in the same
function. |
| CVE-2026-46133 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/rxe: Reject unknown opcodes before ICRC
processing Even after applying commit 7244491dab34
("RDMA/rxe: Validate pad and ICRC before
payload_size() in rxe_rcv"), a single
unauthenticated UDP packet can still trigger
panic. That patch handled payload_size() underflow
only for valid opcodes with short packets, not for
packets carrying an unknown opcode. The
unknown-opcode OOB read described below predates
that commit and reaches back to the initial Soft
RoCE driver. The check added there reads
pkt->paylen < header_size(pkt) +
bth_pad(pkt) + RXE_ICRC_SIZE where
header_size(pkt) expands to
rxe_opcode[pkt->opcode].length. The
rxe_opcode[] array has 256 entries but is only
populated for defined IB opcodes; any other entry
(for example opcode 0xff) is zero-initialized, so
length == 0 and the check degenerates to
pkt->paylen < 0 + bth_pad(pkt) +
RXE_ICRC_SIZE which does not constrain
pkt->paylen enough. rxe_icrc_hdr() then
computes rxe_opcode[pkt->opcode].length -
RXE_BTH_BYTES which underflows when length == 0
and passes a huge value to rxe_crc32(), causing an
out-of-bounds read of the skb payload. Reproduced
on v7.0-rc7 with that fix applied, QEMU/KVM with
CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma
link add rxe0 type rxe netdev eth0 A single
48-byte UDP packet to port 4791 with BTH
opcode=0xff and QPN=IB_MULTICAST_QPN triggers:
BUG: KASAN: slab-out-of-bounds in
crc32_le+0x115/0x170 Read of size 1 at addr ...
The buggy address is located 0 bytes to the right
of allocated 704-byte region Call Trace:
crc32_le+0x115/0x170
rxe_icrc_hdr.isra.0+0x226/0x300
rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0
rxe_udp_encap_recv+0x20a/0x320
udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent
packets with the same shape fault on unmapped
memory and panic the kernel. The trigger requires
only module load and "rdma link add"; no QP, no
connection, and no authentication. Fix this by
rejecting packets whose opcode has no rxe_opcode[]
entry, detected via the zero mask or zero length,
before any length arithmetic runs. |
| CVE-2026-46135 |
In the Linux kernel, the
following vulnerability has been resolved:
nvmet-tcp: fix race between ICReq handling and
queue teardown nvmet_tcp_handle_icreq() updates
queue->state after sending an Initialization
Connection Response (ICResp), but it does so
without serializing against target-side queue
teardown. If an NVMe/TCP host sends an
Initialization Connection Request (ICReq) and
immediately closes the connection, target-side
teardown may start in softirq context before
io_work drains the already buffered ICReq. In that
case, nvmet_tcp_schedule_release_queue() sets
queue->state to NVMET_TCP_Q_DISCONNECTING and
drops the queue reference under state_lock. If
io_work later processes that ICReq,
nvmet_tcp_handle_icreq() can still overwrite the
state back to NVMET_TCP_Q_LIVE. That defeats the
DISCONNECTING-state guard in
nvmet_tcp_schedule_release_queue() and allows a
later socket state change to re-enter teardown and
issue a second kref_put() on an already released
queue. The ICResp send failure path has the same
problem. If teardown has already moved the queue
to DISCONNECTING, a send error can still overwrite
the state with NVMET_TCP_Q_FAILED, again reopening
the window for a second teardown path to drop the
queue reference. Fix this by serializing both
post-send state transitions with state_lock and
bailing out if teardown has already started. Use
-ESHUTDOWN as an internal sentinel for that
bail-out path rather than propagating it as a
transport error like -ECONNRESET. Keep
nvmet_tcp_socket_error() setting rcv_state to
NVMET_TCP_RECV_ERR before honoring that sentinel
so receive-side parsing stays quiesced until the
existing release path completes. |
| CVE-2026-46136 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
mt76: mt7921: fix a potential clc buffer length
underflow The buf_len is used to limit the
iterations for retrieving the country power
setting and may underflow under certain conditions
due to changes in the power table in CLC. This
underflow leads to an almost infinite loop or an
invalid power setting resulting in driver
initialization failure. |
| CVE-2026-46137 |
In the Linux kernel, the
following vulnerability has been resolved: mptcp:
pm: ADD_ADDR rtx: fix potential data-race This
mptcp_pm_add_timer() helper is executed as a timer
callback in softirq context. To avoid any data
races, the socket lock needs to be held with
bh_lock_sock(). If the socket is in use, retry
again soon after, similar to what is done with the
keepalive timer. |
| CVE-2026-46138 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: hci_event: Fix OOB read and infinite
loop in hci_le_create_big_complete_evt
hci_le_create_big_complete_evt() iterates over
BT_BOUND connections for a BIG handle using a
while loop, accessing ev->bis_handle[i++] on
each iteration. However, there is no check that i
stays within ev->num_bis before the array
access. When a controller sends a
LE_Create_BIG_Complete event with fewer bis_handle
entries than there are BT_BOUND connections for
that BIG, or with num_bis=0, the loop reads beyond
the valid bis_handle[] flex array into adjacent
heap memory. Since the out-of-bounds values
typically exceed HCI_CONN_HANDLE_MAX (0x0EFF),
hci_conn_set_handle() rejects them and the
connection remains in BT_BOUND state. The same
connection is then found again by
hci_conn_hash_lookup_big_state(), creating an
infinite loop with hci_dev_lock held. Fix this by
terminating the BIG if in case not all BIS could
be setup properly. |
| CVE-2026-46139 |
In the Linux kernel, the
following vulnerability has been resolved: smb:
client: use kzalloc to zero-initialize security
descriptor buffer Commit 62e7dd0a39c2d ("smb:
common: change the data type of num_aces to le16")
split struct smb_acl's __le32 num_aces field into
__le16 num_aces and __le16 reserved. The reserved
field corresponds to Sbz2 in the MS-DTYP ACL wire
format, which must be zero [1]. When building an
ACL descriptor in build_sec_desc(), we are using a
kmalloc()'ed descriptor buffer and writing the
fields explicitly using le16() writes now. This
never writes to the 2 byte reserved field, leaving
it as uninitialized heap data. When the reserved
field happens to contain non-zero slab garbage,
Samba rejects the security descriptor with
"ndr_pull_security_descriptor failed: Range
Error", causing chmod to fail with EINVAL. Change
kmalloc() to kzalloc() to ensure the entire buffer
is zero-initialized. [1]
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428 |
| CVE-2026-46142 |
In the Linux kernel, the
following vulnerability has been resolved: net:
libwx: fix VF illegal register access Register
WX_CFG_PORT_ST is a PF restricted register. When a
VF is initialized, attempting to read this
register triggers an illegal register access,
which lead to a system hang. When the device is
VF, the bus function ID can be obtained directly
from the PCI_FUNC(pdev->devfn). |
| CVE-2026-46143 |
In the Linux kernel, the
following vulnerability has been resolved: ASoC:
qcom: q6apm-lpass-dai: Fix multiple graph opens As
prepare can be called mulitple times, this can
result in multiple graph opens for playback path.
This will result in a memory leaks, fix this by
adding a check before opening. |
| CVE-2026-46144 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/mana: Fix error unwind in
mana_ib_create_qp_rss() Sashiko points out that
mana_ib_cfg_vport_steering() is leaked, the normal
destroy path cleans it up. |
| CVE-2026-46145 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/mana: Validate rx_hash_key_len Sashiko points
out that rx_hash_key_len comes from a uAPI
structure and is blindly passed to memcpy,
allowing the userspace to trash kernel memory.
Bounds check it so the memcpy cannot
overflow. |
| CVE-2026-46146 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
usb-audio: Avoid potential endless loop in
convert_chmap_v3() The convert_chmap_v3() has a
loop with its increment size of
cs_desc->wLength, but we forgot to validate
cs_desc->wLength itself, which may lead to
potential endless loop by a malformed descriptor.
Add a proper size check to abort the loop for
plugging the hole. |
| CVE-2026-46147 |
In the Linux kernel, the
following vulnerability has been resolved: KVM:
arm64: Fix pin leak and publication ordering in
__pkvm_init_vcpu() Two bugs exist in the vCPU
initialisation path: 1. If a check fails after
hyp_pin_shared_mem() succeeds, the cleanup path
jumps to 'unlock' without calling
unpin_host_vcpu() or unpin_host_sve_state(),
permanently leaking pin references on the host
vCPU and SVE state pages. Extract a
register_hyp_vcpu() helper that performs the
checks and the store. When register_hyp_vcpu()
returns an error, call unpin_host_vcpu() and
unpin_host_sve_state() inline before falling
through to the existing 'unlock' label. 2.
register_hyp_vcpu() publishes the new vCPU pointer
into 'hyp_vm->vcpus[]' with a bare store,
allowing a concurrent caller of
pkvm_load_hyp_vcpu() to observe a partially
initialised vCPU object. Ensure the store uses
smp_store_release() and the load uses
smp_load_acquire(). While 'vm_table_lock'
currently serialises the store and the load, these
barriers ensure the reader sees the fully
initialised 'hyp_vcpu' object even if there were a
lockless path or if the lock's own ordering
guarantees were insufficient for nested object
initialization. |
| CVE-2026-46148 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
microchip-core-qspi: control built-in cs manually
The coreQSPI IP supports only a single chip
select, which is automagically operated by the
hardware - set low when the transmit buffer first
gets written to and set high when the number of
bytes written to the TOTALBYTES field of the
FRAMES register have been sent on the bus.
Additional devices must use GPIOs for their chip
selects. It was reported to me that if there are
two devices attached to this QSPI controller that
the in-built chip select is set low while linux
tries to access the device attached to the GPIO.
This went undetected as the boards that connected
multiple devices to the SPI controller all
exclusively used GPIOs for chip selects, not
relying on the built-in chip select at all. It
turns out that this was because the built-in chip
select, when controlled automagically, is set low
when active and high when inactive, thereby ruling
out its use for active-high devices or devices
that need to transmit with the chip select
disabled. Modify the driver so that it controls
chip select directly, retaining the behaviour for
mem_ops of setting the chip select active for the
entire duration of the transfer in the exec_op
callback. For regular transfers, implement the
set_cs callback for the core to use. As part of
this, the existing setup callback,
mchp_coreqspi_setup_op(), is removed. Modifying
the CLKIDLE field is not safe to do during
operation when there are multiple devices, so this
code is removed entirely. Setting the MASTER and
ENABLE fields is something that can be done once
at probe, it doesn't need to be re-run for each
device. Instead the new setup callback sets the
built-in chip select to its inactive state for
active-low devices, as the reset value of the chip
select in software controlled mode is low. |
| CVE-2026-46149 |
In the Linux kernel, the
following vulnerability has been resolved: scsi:
target: configfs: Bound snprintf() return in
tg_pt_gp_members_show()
target_tg_pt_gp_members_show() formats LUN paths
with snprintf() into a 256-byte stack buffer, then
will memcpy() cur_len bytes from that buffer.
snprintf() returns the length the output would
have had, which can exceed the buffer size when
the fabric WWN is long because iSCSI IQN names can
be up to 223 bytes. The check at the memcpy() site
only guards the destination page write, not the
source read, so memcpy() will read past the stack
buffer and copy adjacent stack contents to the
sysfs reader, which when CONFIG_FORTIFY_SOURCE is
enabled, fortify_panic() will be triggered. Commit
27e06650a5ea ("scsi: target: target_core_configfs:
Add length check to avoid buffer overflow") added
the same bound to the target_lu_gp_members_show()
but the tg_pt_gp variant was missed so resolve
that here. |
| CVE-2026-46150 |
In the Linux kernel, the
following vulnerability has been resolved:
fanotify: fix false positive on permission events
fsnotify_get_mark_safe() may return false for a
mark on an unrelated group, which results in
bypassing the permission check. Fix by skipping
over detached marks that are not in the current
group. |
| CVE-2026-46151 |
In the Linux kernel, the
following vulnerability has been resolved: usb:
usblp: fix heap leak in IEEE 1284 device ID via
short response usblp_ctrl_msg() collapses the
usb_control_msg() return value to 0/-errno,
discarding the actual number of bytes transferred.
A broken printer can complete the GET_DEVICE_ID
control transfer short and the driver has no way
to know. usblp_cache_device_id_string() reads the
2-byte big-endian length prefix from the response
and trusts it (clamped only to the buffer bounds).
The buffer is kmalloc(1024) at probe time. A
device that sends exactly two bytes (e.g. 0x03
0xFF, claiming a 1023-byte ID) leaves
device_id_string[2..1022] holding stale kmalloc
heap. That stale data is then exposed: - via the
ieee1284_id sysfs attribute (sprintf("%s", buf+2),
truncated at the first NUL in the stale heap), and
- via the IOCNR_GET_DEVICE_ID ioctl, which
copy_to_user()s the full claimed length regardless
of NULs, up to 1021 bytes of uninitialized heap,
with the leak size chosen by the device. Fix this
up by just zapping the buffer with zeros before
each request sent to the device. |
| CVE-2026-46152 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
mac80211: drop stray 'static' from fast-RX
rx_result ieee80211_invoke_fast_rx() is documented
as safe for parallel RX, but its per-invocation
rx_result is declared static. Concurrent callers
then share one instance and can overwrite each
other's result between ieee80211_rx_mesh_data()
and the switch on res. That can make a packet that
was queued or consumed by ieee80211_rx_mesh_data()
fall through into ieee80211_rx_8023(), or make a
packet that should continue return as queued. Make
res an automatic variable so each invocation keeps
its own result. |
| CVE-2026-46153 |
In the Linux kernel, the
following vulnerability has been resolved: 8021q:
delete cleared egress QoS mappings
vlan_dev_set_egress_priority() currently keeps
cleared egress priority mappings in the hash as
tombstones. Repeated set/clear cycles with
distinct skb priorities therefore accumulate
mapping nodes until device teardown and leak
memory. Delete mappings when vlan_prio is cleared
instead of keeping tombstones. Now that the egress
mapping lists are RCU protected, the node can be
unlinked safely and freed after a grace
period. |
| CVE-2026-46157 |
In the Linux kernel, the
following vulnerability has been resolved: ALSA:
pcm: oss: Fix data race at accessing
runtime.oss.trigger Currently the
runtime.oss.trigger field may be accessed
concurrently without protection, which may lead to
the data race. And, in this case, it may lead to
more severe problem because it's a bit field; as
writing the data, it may overwrite other bit
fields as well, which confuses the operation
completely, as spotted by fuzzing. Fix it by
covering runtime.oss.trigger bit fled also with
the existing params_lock mutex in both
snd_pcm_oss_get_trigger() and
snd_pcm_oss_poll(). |
| CVE-2026-46158 |
In the Linux kernel, the
following vulnerability has been resolved: mptcp:
pm: ADD_ADDR rtx: always decrease sk refcount When
an ADD_ADDR is retransmitted, the sk is held in
sk_reset_timer(). It should then be released in
all cases at the end. Some (unlikely) checks were
returning directly instead of calling sock_put()
to decrease the refcount. Jump to a new 'exit'
label to call __sock_put() (which will become
sock_put() in the next commit) to fix this
potential leak. While at it, drop the '!msk' check
which cannot happen because it is never reset, and
explicitly mark the remaining one as
"unlikely". |
| CVE-2026-46159 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
fix btrfs_ioctl_space_info() slot_count TOCTOU
which can lead to info-leak
btrfs_ioctl_space_info() has a TOCTOU race between
two passes over the block group RAID type lists.
The first pass counts entries to determine the
allocation size, then the second pass fills the
buffer. The groups_sem rwlock is released between
passes, allowing concurrent block group removal to
reduce the entry count. When the second pass fills
fewer entries than the first pass counted,
copy_to_user() copies the full alloc_size bytes
including trailing uninitialized kmalloc bytes to
userspace. Fix by copying only total_spaces
entries (the actually-filled count from the second
pass) instead of alloc_size bytes, and switch to
kzalloc so any future copy size mismatch cannot
leak heap data. |
| CVE-2026-46160 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
fix missing last_unlink_trans update when removing
a directory When removing a directory we are not
updating its last_unlink_trans field, which can
result in incorrect fsync behaviour in case some
one fsyncs the directory after it was removed
because it's holding a file descriptor on it.
Example scenario: mkdir /mnt/dir1 mkdir
/mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do
some change to the directory and fsync it. chmod
700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move
dir2 out of dir1 so that dir1 becomes empty. mv
/mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1
call rmdir(2) on path "/mnt/dir1" fsync fd
<trigger power failure> When attempting to
mount the filesystem, the log replay will fail
with an -EIO error and dmesg/syslog has the
following: [445771.626482] BTRFS info (device
dm-0): first mount of filesystem
0368bbea-6c5e-44b5-b409-09abe496e650
[445771.626486] BTRFS info (device dm-0): using
crc32c checksum algorithm [445771.627912] BTRFS
info (device dm-0): start tree-log replay
[445771.628335] page: refcount:2 mapcount:0
mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5
[445771.629453] memcg:ffff89f400351b00
[445771.629892] aops:btree_aops [btrfs] ino:1
[445771.630737] flags:
0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)
[445771.632359] raw: 017fffc00000402a
fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8
[445771.633713] raw: 0000000000001d00
ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00
[445771.635029] page dumped because: eb page dump
[445771.635825] BTRFS critical (device dm-0):
corrupt leaf: root=5 block=30408704 slot=10
ino=258, invalid nlink: has 2 expect no more than
1 for dir [445771.638088] BTRFS info (device
dm-0): leaf 30408704 gen 10 total ptrs 17 free
space 14878 owner 5 [445771.638091] BTRFS info
(device dm-0): refs 4 lock_owner 0 current 3581087
[445771.638094] item 0 key (256 INODE_ITEM 0)
itemoff 16123 itemsize 160 [445771.638097] inode
generation 3 transid 9 size 16 nbytes 16384
[445771.638098] block group 0 mode 40755 links 1
uid 0 gid 0 [445771.638100] rdev 0 sequence 2
flags 0x0 [445771.638102] atime 1775744884.0
[445771.660056] ctime 1775744885.645502983
[445771.660058] mtime 1775744885.645502983
[445771.660060] otime 1775744884.0 [445771.660062]
item 1 key (256 INODE_REF 256) itemoff 16111
itemsize 12 [445771.660064] index 0 name_len 2
[445771.660066] item 2 key (256 DIR_ITEM
1843588421) itemoff 16077 itemsize 34
[445771.660068] location key (259 1 0) type 2
[445771.660070] transid 9 data_len 0 name_len 4
[445771.660075] item 3 key (256 DIR_ITEM
2363071922) itemoff 16043 itemsize 34
[445771.660076] location key (257 1 0) type 2
[445771.660077] transid 9 data_len 0 name_len 4
[445771.660078] item 4 key (256 DIR_INDEX 2)
itemoff 16009 itemsize 34 [445771.660079] location
key (257 1 0) type 2 [445771.660080] transid 9
data_len 0 name_len 4 [445771.660081] item 5 key
(256 DIR_INDEX 3) itemoff 15975 itemsize 34
[445771.660082] location key (259 1 0) type 2
[445771.660083] transid 9 data_len 0 name_len 4
[445771.660084] item 6 key (257 INODE_ITEM 0)
itemoff 15815 itemsize 160 [445771.660086] inode
generation 9 transid 9 size 8 nbytes 0
[445771.660087] block group 0 mode 40777 links 1
uid 0 gid 0 [445771.660088] rdev 0 sequence 2
flags 0x0 [445771.660089] atime
1775744885.641174097 [445771.660090] ctime
1775744885.645502983 [445771.660091] mtime
1775744885.645502983 [445771.660105] otime
1775744885.641174097 [445771.660106] item 7 key
(257 INODE_REF 256) itemoff 15801 itemsize 14
[445771.660107] index 2 name_len 4 [445771.660108]
item 8 key (257 DIR_ITEM 2676584006) itemoff 15767
itemsize 34 [445771.660109] location key (2
---truncated--- |
| CVE-2026-46161 |
In the Linux kernel, the
following vulnerability has been resolved:
md/raid10: fix divide-by-zero in setup_geo() with
zero far_copies setup_geo() extracts near_copies
(nc) and far_copies (fc) from the user-provided
layout parameter without checking for zero. When
fc=0 with the "improved" far set layout selected,
'geo->far_set_size = disks / fc' triggers a
divide-by-zero. Validate nc and fc immediately
after extraction, returning -1 if either is
zero. |
| CVE-2026-46163 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
b43legacy: enforce bounds check on firmware key
index in RX path Same fix as b43: the
firmware-controlled key index in b43legacy_rx()
can exceed dev->max_nr_keys. The existing
B43legacy_WARN_ON is non-enforcing in production
builds, allowing an out-of-bounds read of
dev->key[]. Make the check enforcing by
dropping the frame for invalid indices. |
| CVE-2026-46164 |
In the Linux kernel, the
following vulnerability has been resolved: btrfs:
fix double free in create_space_info_sub_group()
error path When kobject_init_and_add() fails, the
call chain is: create_space_info_sub_group() ->
btrfs_sysfs_add_space_info_type() ->
kobject_init_and_add() -> failure ->
kobject_put(&sub_group->kobj) ->
space_info_release() -> kfree(sub_group) Then
control returns to create_space_info_sub_group(),
where: btrfs_sysfs_add_space_info_type() returns
error -> kfree(sub_group) Thus, sub_group is
freed twice. Keep parent->sub_group[index] =
NULL for the failure path, but after
btrfs_sysfs_add_space_info_type() has called
kobject_put(), let the kobject release callback
handle the cleanup. |
| CVE-2026-46167 |
In the Linux kernel, the
following vulnerability has been resolved: usb:
usblp: fix uninitialized heap leak via LPGETSTATUS
ioctl Just like in a previous problem in this
driver, usblp_ctrl_msg() will collapse the
usb_control_msg() return value to 0/-errno,
discarding the actual number of bytes transferred.
Ideally that short command should be detected and
error out, but many printers are known to send
"incorrect" responses back so we can't just do
that. statusbuf is kmalloc(8) at probe time and
never filled before the first LPGETSTATUS ioctl.
usblp_read_status() requests 1 byte. If a
malicious printer responds with zero bytes,
*statusbuf is one byte of stale kmalloc heap,
sign-extended into the local int status, which the
LPGETSTATUS path then copy_to_user()s directly to
the ioctl caller. Fix this all by just zapping out
the memory buffer when allocated at probe time. If
a later call does a short read, the data will be
identical to what the device sent it the last
time, so there is no "leak" of information
happening. |
| CVE-2026-46168 |
In the Linux kernel, the
following vulnerability has been resolved: mptcp:
fix scheduling with atomic in timestamp sockopt
Using lock_sock_fast() (atomic context) around
sock_set_timestamp() and sock_set_timestamping()
is unsafe, as both helpers can sleep. Replace
lock_sock_fast() with sleepable
lock_sock()/release_sock() to avoid scheduling
while atomic panic. |
| CVE-2026-46169 |
In the Linux kernel, the
following vulnerability has been resolved:
hfsplus: fix uninit-value by validating catalog
record size Syzbot reported a KMSAN uninit-value
issue in hfsplus_strcasecmp(). The root cause is
that hfs_brec_read() doesn't validate that the
on-disk record size matches the expected size for
the record type being read. When mounting a
corrupted filesystem, hfs_brec_read() may read
less data than expected. For example, when reading
a catalog thread record, the debug output showed:
HFSPLUS_BREC_READ: rec_len=520,
fd->entrylength=26 HFSPLUS_BREC_READ: WARNING -
entrylength (26) < rec_len (520) - PARTIAL
READ! hfs_brec_read() only validates that
entrylength is not greater than the buffer size,
but doesn't check if it's less than expected. It
successfully reads 26 bytes into a 520-byte
structure and returns success, leaving 494 bytes
uninitialized. This uninitialized data in
tmp.thread.nodeName then gets copied by
hfsplus_cat_build_key_uni() and used by
hfsplus_strcasecmp(), triggering the KMSAN warning
when the uninitialized bytes are used as array
indices in case_fold(). Fix by introducing
hfsplus_brec_read_cat() wrapper that: 1. Calls
hfs_brec_read() to read the data 2. Validates the
record size based on the type field: - Fixed size
for folder and file records - Variable size for
thread records (depends on string length) 3.
Returns -EIO if size doesn't match expected For
thread records, check against
HFSPLUS_MIN_THREAD_SZ before reading
nodeName.length to avoid reading uninitialized
data at call sites that don't zero-initialize the
entry structure. Also initialize the tmp variable
in hfsplus_find_cat() as defensive programming to
ensure no uninitialized data even if validation is
bypassed. |
| CVE-2026-46170 |
In the Linux kernel, the
following vulnerability has been resolved: mptcp:
pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR
is retransmitted, the sk is held in
sk_reset_timer(), and released at the end. If at
that moment, it was the last reference being held,
the sk would not be freed. sock_put() should then
be called instead of __sock_put(). But that's not
enough: if it is the last reference, sock_put()
will call sk_free(), which will end up calling
sk_stop_timer_sync() on the same timer, and
waiting indefinitely to finish. So it is needed to
mark that the timer is done at the end of the
timer handler when it has not been rescheduled,
not to call sk_stop_timer_sync() on
"itself". |
| CVE-2026-46171 |
In the Linux kernel, the
following vulnerability has been resolved: riscv:
kvm: fix vector context allocation leak When the
second kzalloc (host_context.vector.datap) fails
in kvm_riscv_vcpu_alloc_vector_context, the first
allocation (guest_context.vector.datap) is leaked.
Free it before returning. |
| CVE-2026-46172 |
In the Linux kernel, the
following vulnerability has been resolved: ipv6:
xfrm6: release dst on error in xfrm6_rcv_encap()
xfrm6_rcv_encap() performs an IPv6 route lookup
when the skb does not already have a dst attached.
ip6_route_input_lookup() returns a referenced dst
entry even when the lookup resolves to an error
route. If dst->error is set, xfrm6_rcv_encap()
drops the skb without attaching the dst to the skb
and without releasing the reference returned by
the lookup. Repeated packets hitting this path
therefore leak dst entries. Release the dst before
jumping to the drop path. |
| CVE-2026-46173 |
In the Linux kernel, the
following vulnerability has been resolved: exit:
prevent preemption of oopsing TASK_DEAD task When
an already-exiting task oopses, make_task_dead()
currently calls do_task_dead() with preemption
enabled. That is forbidden: do_task_dead() calls
__schedule(), which has a comment saying "WARNING:
must be called with preemption disabled!". If an
oopsing task is preempted in do_task_dead(),
between becoming TASK_DEAD and entering the
scheduler explicitly, bad things happen:
finish_task_switch() assumes that once the
scheduler has switched away from a TASK_DEAD task,
the task can never run again and its stack is no
longer needed; but that assumption apparently
doesn't hold if the dead task was preempted (the
SM_PREEMPT case). This means that the scheduler
ends up repeatedly dropping references on the dead
task's stack, which can lead to use-after-free or
double-free of the entire task stack; in other
words, two tasks can end up running on the same
stack, resulting in various kinds of memory
corruption. (This does not just affect
"recursively oopsing" tasks; it is enough to oops
once during task exit, for example in a
file_operations::release handler) |
| CVE-2026-46174 |
In the Linux kernel, the
following vulnerability has been resolved:
x86/CPU/AMD: Prevent improper isolation of shared
resources in Zen2's op cache Make sure resources
are not improperly shared in the op cache and
cause instruction corruption this way. |
| CVE-2026-46175 |
In the Linux kernel, the
following vulnerability has been resolved: f2fs:
fix fsck inconsistency caused by FGGC of node
block During FGGC node block migration, fsck may
incorrectly treat the migrated node block as
fsync-written data. The reproduction scenario:
root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1
./test_sync // write inline inode and sync
root@vm:/mnt/f2fs# rm -f 1 root@vm:/mnt/f2fs# sync
root@vm:/mnt/f2fs# f2fs_io gc_range // move data
block in sync mode and not write CP SPO, "fsck
--dry-run" find inode has already checkpointed but
still with DENT_BIT_SHIFT set The root cause is
that GC does not clear the dentry mark and fsync
mark during node block migration, leading fsck to
misinterpret them as user-issued fsync writes. In
BGGC mode, node block migration is handled by
f2fs_sync_node_pages(), which guarantees the
dentry and fsync marks are cleared before writing.
This patch move the set/clear of the fsync|dentry
marks into __write_node_folio to make the logic
clearer, and ensures the fsync|dentry mark is
cleared in FGGC. |
| CVE-2026-46176 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/mlx5: Fix error path fall-through in
mlx5_ib_dev_res_srq_init()
mlx5_ib_dev_res_srq_init() allocates two SRQs, s0
and s1. When ib_create_srq() fails for s1, the
error branch destroys s0 but falls through and
unconditionally assigns the freed s0 and the
ERR_PTR s1 to devr->s0 and devr->s1. This
leads to several problems: the lock-free fast path
checks "if (devr->s1) return 0;" and treats the
ERR_PTR as already initialised; users in
mlx5_ib_create_qp() dereference the freed SRQ or
ERR_PTR via to_msrq(devr->s0)->msrq.srqn;
and mlx5_ib_dev_res_cleanup() dereferences the
ERR_PTR and double-frees s0 on teardown. Fix by
adding the same `goto unlock` in the s1 failure
path. |
| CVE-2026-46177 |
In the Linux kernel, the
following vulnerability has been resolved: ipmi:
Add limits to event and receive message requests
The driver would just fetch events and receive
messages until the BMC said it was done. To avoid
issues with BMCs that never say they are done, add
a limit of 10 fetches at a time. In addition, an
si interface has an attn state it can return from
the hardware which is supposed to cause a flag
fetch to see if the driver needs to fetch events
or message or a few other things. If the attn bit
gets stuck, it's a similar problem. So allow
messages in between flag fetches so the driver
itself doesn't get stuck. This is a more general
fix than the previous fix for the specific bad
BMC, but should fix the more general issue of a
BMC that won't stop saying it has data. This has
been there from the beginning of the driver. It's
not a bug per-se, but it is accounting for bugs in
BMCs. |
| CVE-2026-46178 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/mlx4: Fix resource leak on error in
mlx4_ib_create_srq() Sashiko points out that
mlx4_srq_alloc() was not undone during error
unwind, add the missing call to
mlx4_srq_free(). |
| CVE-2026-46179 |
In the Linux kernel, the
following vulnerability has been resolved: ASoC:
SOF: Don't allow pointer operations on
unconfigured streams When reporting the pointer
for a compressed stream we report the current I/O
frame position by dividing the position by the
number of channels multiplied by the number of
container bytes. These values default to 0 and are
only configured as part of setting the stream
parameters so this allows a divide by zero to be
configured. Validate that they are non zero,
returning an error if not |
| CVE-2026-46180 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
brcmfmac: Fix potential use-after-free issue when
stopping watchdog task Watchdog task might end
between send_sig() and kthread_stop() calls, what
results in the use-after-free issue. Fix this by
increasing watchdog task reference count before
calling send_sig() and dropping it by switching to
kthread_stop_put(). |
| CVE-2026-46181 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()
Sashiko points out the radix_tree itself is RCU
safe, but nothing ever frees the mlx4_srq struct
with RCU, and it isn't even accessed within the
RCU critical section. It also will crash if an
event is delivered before the srq object is
finished initializing. Use the spinlock since it
isn't easy to make RCU work, use
refcount_inc_not_zero() to protect against
partially initialized objects, and order the
refcount_set() to be after the srq is fully
initialized. |
| CVE-2026-46184 |
In the Linux kernel, the
following vulnerability has been resolved: sound:
ua101: fix division by zero at probe Add a missing
sanity check for bNrChannels in
detect_usb_format() to prevent a division by zero
in playback_urb_complete() and
capture_urb_complete(). USB core does not validate
class-specific descriptor fields such as
bNrChannels, so drivers must verify them before
use. If a device provides bNrChannels = 0,
frame_bytes becomes zero and is later used as a
divisor in the URB completion handlers, leading to
a kernel crash. |
| CVE-2026-46185 |
In the Linux kernel, the
following vulnerability has been resolved:
smb/client: fix out-of-bounds read in
symlink_data() Since smb2_check_message() returns
success without length validation for the symlink
error response, in symlink_data() it is possible
for iov->iov_len to be smaller than
sizeof(struct smb2_err_rsp). If the buffer only
contains the base SMB2 header (64 bytes),
accessing err->ErrorContextCount (at offset 66)
or err->ByteCount later in symlink_data() will
cause an out-of-bounds read. |
| CVE-2026-46186 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: virtio_bt: validate rx pkt_type header
length virtbt_rx_handle() reads the leading
pkt_type byte from the RX skb and forwards the
remainder to hci_recv_frame() for every
event/ACL/SCO/ISO type, without checking that the
remaining payload is at least the fixed HCI header
for that type. After the preceding patch bounds
the backend-supplied used.len to [1,
VIRTBT_RX_BUF_SIZE], a one-byte completion still
reaches hci_recv_frame() with skb->len already
pulled to 0. If the byte happened to be
HCI_ACLDATA_PKT, the ACL-vs-ISO classification
fast-path in hci_dev_classify_pkt_type()
dereferences hci_acl_hdr(skb)->handle whenever
the HCI device has an active CIS_LINK, BIS_LINK,
or PA_LINK connection, reading two bytes of
uninitialized RX-buffer data. The same hazard
exists for every packet type the driver accepts
because none of the switch cases in
virtbt_rx_handle() check skb->len against the
per-type minimum HCI header size before handing
the frame to the core. After stripping pkt_type,
require skb->len to cover the fixed header size
for the selected type (event 2, ACL 4, SCO 3, ISO
4) before calling hci_recv_frame(); drop
ratelimited otherwise. Unknown pkt_type values
still take the original kfree_skb() default path.
Use bt_dev_err_ratelimited() because both the
length and pkt_type values come from an untrusted
backend that can otherwise flood the kernel
log. |
| CVE-2026-46187 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
rsi: fix kthread lifetime race between self-exit
and external-stop RSI driver use both
self-exit(kthread_complete_and_exit) and
external-stop (kthread_stop) when killing a
kthread. Generally, kthread_stop() is called
first, and in this case, no particular issues
occur. However, in rare instances where
kthread_complete_and_exit() is called first and
then kthread_stop() is called, a UAF occurs
because the kthread object, which has already
exited and been freed, is accessed again.
Therefore, to prevent this with minimal
modification, you must remove kthread_stop() and
change the code to wait until the self-exit
operation is completed. |
| CVE-2026-46189 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/vmw_pvrdma: Fix double free on
pvrdma_alloc_ucontext() error path Sashiko points
out that pvrdma_uar_free() is already called
within pvrdma_dealloc_ucontext(), so calling it
before triggers a double free. |
| CVE-2026-46190 |
In the Linux kernel, the
following vulnerability has been resolved: mtd:
spi-nor: debugfs: fix out-of-bounds read in
spi_nor_params_show() Sashiko noticed an
out-of-bounds read [1]. In spi_nor_params_show(),
the snor_f_names array is passed to
spi_nor_print_flags() using sizeof(snor_f_names).
Since snor_f_names is an array of pointers,
sizeof() returns the total number of bytes
occupied by the pointers (element_count *
sizeof(void *)) rather than the element count
itself. On 64-bit systems, this makes the passed
length 8x larger than intended. Inside
spi_nor_print_flags(), the 'names_len' argument is
used to bounds-check the 'names' array access. An
out-of-bounds read occurs if a flag bit is set
that exceeds the array's actual element count but
is within the inflated byte-size count. Correct
this by using ARRAY_SIZE() to pass the actual
number of string pointers in the array. |
| CVE-2026-46191 |
In the Linux kernel, the
following vulnerability has been resolved: fbcon:
Avoid OOB font access if console rotation fails
Clear the font buffer if the reallocation during
console rotation fails in fbcon_rotate_font(). The
putcs implementations for the rotated buffer will
return early in this case. See [1] for an example.
Currently, fbcon_rotate_font() keeps the old
buffer, which is too small for the rotated font.
Printing to the rotated console with a high-enough
character code will overflow the font buffer. v2:
- fix typos in commit message |
| CVE-2026-46193 |
In the Linux kernel, the
following vulnerability has been resolved: xfrm:
ah: account for ESN high bits in async callbacks
AH allocates its temporary auth/ICV layout
differently when ESN is enabled: the async ahash
setup appends a 4-byte seqhi slot before the ICV
or auth_data area, but the async completion
callbacks still reconstruct the temporary layout
as if seqhi were absent. With an async AH
implementation selected, that makes AH copy or
compare the wrong bytes on both the IPv4 and IPv6
paths. In UML repro on IPv4 AH with ESN and forced
async hmac(sha1), ping fails with 100% packet
loss, and the callback logs show the pre-fix
drift: ah4 output_done: esn=1 err=0 icv_off=20
expected_off=24 ah4 input_done: esn=1 auth_off=20
expected_auth_off=24 icv_off=32
expected_icv_off=36 Reconstruct the callback-side
layout the same way the setup path built it by
skipping the ESN seqhi slot before locating the
saved auth_data or ICV. Per RFC 4302, the ESN
high-order 32 bits participate in the AH ICV
computation, so the async callbacks must account
for the seqhi slot. Post-fix, the same IPv4
AH+ESN+forced-async-hmac(sha1) UML repro shows the
corrected offset (ah4 output_done: esn=1 err=0
icv_off=24 expected_off=24) and ping succeeds;
net/ipv4/ah4.o and net/ipv6/ah6.o build clean at
W=1. IPv6 AH+ESN was not exercised at runtime, and
the change has not been tested against a real
async hardware AH engine. |
| CVE-2026-46194 |
In the Linux kernel, the
following vulnerability has been resolved: f2fs:
fix node_cnt race between extent node destroy and
writeback f2fs_destroy_extent_node() does not set
FI_NO_EXTENT before clearing extent nodes. When
called from f2fs_drop_inode() with I_SYNC set,
concurrent kworker writeback can insert new extent
nodes into the same extent tree, racing with the
destroy and triggering f2fs_bug_on() in
__destroy_extent_node(). The scenario is as
follows: drop inode writeback - iput -
f2fs_drop_inode // I_SYNC set -
f2fs_destroy_extent_node - __destroy_extent_node -
while (node_cnt) { write_lock(&et->lock)
__free_extent_tree write_unlock(&et->lock)
- __writeback_single_inode -
f2fs_outplace_write_data -
f2fs_update_read_extent_cache -
__update_extent_tree_range // FI_NO_EXTENT not
set, // insert new extent node } // node_cnt == 0,
exit while - f2fs_bug_on(node_cnt) // node_cnt
> 0 Additionally, __update_extent_tree_range()
only checks FI_NO_EXTENT for EX_READ type, leaving
EX_BLOCK_AGE updates completely unprotected. This
patch set FI_NO_EXTENT under et->lock in
__destroy_extent_node(), consistent with other
callers (__update_extent_tree_range and
__drop_extent_tree) and check FI_NO_EXTENT for
both EX_READ and EX_BLOCK_AGE tree. |
| CVE-2026-46195 |
In the Linux kernel, the
following vulnerability has been resolved: smb:
client: validate dacloffset before building DACL
pointers parse_sec_desc(), build_sec_desc(), and
the chown path in id_mode_to_cifs_acl() all add
the server-supplied dacloffset to pntsd before
proving a DACL header fits inside the returned
security descriptor. On 32-bit builds a malicious
server can return dacloffset near U32_MAX, wrap
the derived DACL pointer below end_of_acl, and
then slip past the later pointer-based bounds
checks. build_sec_desc() and id_mode_to_cifs_acl()
can then dereference DACL fields from the wrapped
pointer in the chmod/chown rewrite paths. Validate
dacloffset numerically before building any DACL
pointer and reuse the same helper at the three
DACL entry points. |
| CVE-2026-46196 |
In the Linux kernel, the
following vulnerability has been resolved:
tracepoint: balance regfunc() on func_add()
failure in tracepoint_add_func() When a tracepoint
goes through the 0 -> 1 transition,
tracepoint_add_func() invokes the subsystem's
ext->regfunc() before attempting to install the
new probe via func_add(). If func_add() then fails
(for example, when allocate_probes() cannot
allocate a new probe array under memory pressure
and returns -ENOMEM), the function returns the
error without calling the matching
ext->unregfunc(), leaving the side effects of
regfunc() behind with no installed probe to
justify them. For syscall tracepoints this is
particularly unpleasant: syscall_regfunc() bumps
sys_tracepoint_refcount and sets
SYSCALL_TRACEPOINT on every task. After a leaked
failure, the refcount is stuck at a non-zero value
with no consumer, and every task continues paying
the syscall trace entry/exit overhead until
reboot. Other subsystems providing
regfunc()/unregfunc() pairs exhibit similarly
scoped persistent state. Mirror the existing 1
-> 0 cleanup and call ext->unregfunc() in
the func_add() error path, gated on the same
condition used there so the unwind is symmetric
with the registration. |
| CVE-2026-46197 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdkfd: validate SVM ioctl nattr against
buffer size Validate nattr field against the
buffer size, preventing out-of-bounds buffer
access via user-controlled attribute count.
(cherry picked from commit
5eca8bfdfa456c3304ca77523718fe24254c172f) |
| CVE-2026-46198 |
In the Linux kernel, the
following vulnerability has been resolved:
batman-adv: fix integer overflow on buff_pos
Fixing an integer overflow present in
batadv_iv_ogm_send_to_if. The size check is done
using the int type in batadv_iv_ogm_aggr_packet
whereas the buff_pos variable uses the s16 type.
This could lead to an out-of-bound read. |
| CVE-2026-46199 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdgpu/vcn4: Prevent OOB reads when parsing
dec msg Check bounds against the end of the BO
whenever we access the msg. |
| CVE-2026-46200 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
mpc52xx: fix controller deregistration Make sure
to deregister the controller before disabling and
releasing underlying resources like interrupts and
gpios during driver unbind. |
| CVE-2026-46201 |
In the Linux kernel, the
following vulnerability has been resolved: drm/xe:
Fix dma-buf attachment leak in
xe_gem_prime_import() When xe_dma_buf_init_obj()
fails, the attachment from
dma_buf_dynamic_attach() is not detached. Add
dma_buf_detach() before returning the error. Note:
we cannot use goto out_err here because
xe_dma_buf_init_obj() already frees bo on failure,
and out_err would double-free it. (cherry picked
from commit
a828eb185aac41800df8eae4b60501ccc0dbbe51) |
| CVE-2026-46203 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
cadence-quadspi: fix unclocked access on unbind
Make sure that the controller is runtime resumed
before disabling it during driver unbind to avoid
an unclocked register access. This issue was
flagged by Sashiko when reviewing a controller
deregistration fix. |
| CVE-2026-46204 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdgpu/vcn4: Prevent OOB reads when parsing IB
Rewrite the IB parsing to use
amdgpu_ib_get_value() which handles the bounds
checks. |
| CVE-2026-46205 |
In the Linux kernel, the
following vulnerability has been resolved:
staging: media: atomisp: Disallow all private
IOCTLs Disallow all private IOCTLs. These aren't
quite as safe as one could assume of IOCTL
handlers; disable them for now. Instead of
removing the code, return in the beginning of the
function if cmd is non-zero in order to keep
static checkers happy. |
| CVE-2026-46206 |
In the Linux kernel, the
following vulnerability has been resolved:
batman-adv: reject new tp_meter sessions during
teardown Prevent tp_meter from starting new sender
or receiver sessions after mesh_state has left
BATADV_MESH_ACTIVE. |
| CVE-2026-46207 |
In the Linux kernel, the
following vulnerability has been resolved:
vsock/virtio: fix empty payload in tap skb for
non-linear buffers For non-linear skbs,
virtio_transport_build_skb() goes through
virtio_transport_copy_nonlinear_skb() to copy the
original payload in the new skb to be delivered to
the vsockmon tap device. This manually initializes
an iov_iter but does not set iov_iter.count. Since
the iov_iter is zero-initialized, the copy length
is zero and no payload is actually copied to the
monitor interface, leaving data un-initialized.
Fix this by removing the linear vs non-linear
split and using skb_copy_datagram_iter() with
iov_iter_kvec() for all cases, as vhost-vsock
already does. This handles both linear and
non-linear skbs, properly initializes the
iov_iter, and removes the now unused
virtio_transport_copy_nonlinear_skb(). While
touching this code, let's also check the return
value of skb_copy_datagram_iter(), even though
it's unlikely to fail. |
| CVE-2026-46208 |
In the Linux kernel, the
following vulnerability has been resolved:
batman-adv: stop tp_meter sessions during mesh
teardown TP meter sessions remain linked on
bat_priv->tp_list after the netlink request has
already finished. When the mesh interface is
removed, batadv_mesh_free() currently tears down
the mesh without first draining these sessions. A
running sender thread or a late incoming tp_meter
packet can then keep processing against a mesh
instance which is already shutting down.
Synchronize tp_meter with the mesh lifetime by
stopping all active sessions from
batadv_mesh_free() and waiting for sender threads
to exit before teardown continues. |
| CVE-2026-46209 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/gem: Fix inconsistent plane dimension
calculation in drm_gem_fb_init_with_funcs()
drm_gem_fb_init_with_funcs() computes sub-sampled
plane dimensions using plain integer division:
unsigned int width = mode_cmd->width / (i ?
info->hsub : 1); unsigned int height =
mode_cmd->height / (i ? info->vsub : 1);
However, the ioctl-level framebuffer_check() in
drm_framebuffer.c uses
drm_format_info_plane_width/height() which round
up dimensions via DIV_ROUND_UP(). This
inconsistency corrupts the subsequent GEM object
size check for certain pixel format and dimension
combinations. For example, with NV12 (vsub=2) and
a 1-pixel-tall framebuffer the GEM size validation
path sees height=0 instead of height=1. The
expression (height - 1) then wraps to UINT_MAX as
an unsigned int, causing min_size to overflow and
wrap back to a small value. A tiny GEM object
therefore passes the size guard, yet when the GPU
accesses the chroma plane it will read or write
memory beyond the object's bounds. Fix by
replacing the open-coded divisions with
drm_format_info_plane_width() and
drm_format_info_plane_height(), which use
DIV_ROUND_UP() and match the calculation already
used in framebuffer_check(). |
| CVE-2026-46211 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/msm/gem: fix error handling in
msm_ioctl_gem_info_get_metadata()
msm_ioctl_gem_info_get_metadata() always returns 0
regardless of errors. When copy_to_user() fails or
the user buffer is too small, the error code
stored in ret is ignored because the function
unconditionally returns 0. This causes userspace
to believe the ioctl succeeded when it did not.
Additionally, kmemdup() can return NULL on
allocation failure, but the return value is not
checked. This leads to a NULL pointer dereference
in the subsequent copy_to_user() call. Add the
missing NULL check for kmemdup() and return ret
instead of 0. Note that the SET counterpart
(msm_ioctl_gem_info_set_metadata) correctly
returns ret. Patchwork:
https://patchwork.freedesktop.org/patch/714478/ |
| CVE-2026-46212 |
In the Linux kernel, the
following vulnerability has been resolved:
batman-adv: bla: prevent use-after-free when
deleting claims When
batadv_bla_del_backbone_claims() removes all
claims for a backbone, it does this by dropping
the link entry in the hash list. This list entry
itself was one of the references which need to be
dropped at the same time via batadv_claim_put().
But the batadv_claim_put() must not be done before
the last access to the claim object in this
function. Otherwise the claim might be freed
already by the batadv_claim_release() function
before the list entry was dropped. |
| CVE-2026-46214 |
In the Linux kernel, the
following vulnerability has been resolved:
vsock/virtio: fix accept queue count leak on
transport mismatch virtio_transport_recv_listen()
calls sk_acceptq_added() before
vsock_assign_transport(). If
vsock_assign_transport() fails or selects a
different transport, the error path returns
without calling sk_acceptq_removed(), permanently
incrementing sk_ack_backlog. After approximately
backlog+1 such failures, sk_acceptq_is_full()
returns true, causing the listener to reject all
new connections. Fix by moving sk_acceptq_added()
to after the transport validation, matching the
pattern used by vmci_transport and
hyperv_transport. |
| CVE-2026-46218 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdgpu: Add bounds checking to
ib_{get,set}_value The uvd/vce/vcn code accesses
the IB at predefined offsets without checking that
the IB is large enough. Check the bounds here. The
caller is responsible for making sure it can
handle arbitrary return values. Also make the idx
a uint32_t to prevent overflows causing the
condition to fail. |
| CVE-2026-46219 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
mpc52xx: fix use-after-free on unbind The state
machine work is scheduled by the interrupt handler
and therefore needs to be cancelled after
disabling interrupts to avoid a potential
use-after-free. |
| CVE-2026-46220 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in
fence emission sdma_v4_0_ring_emit_fence()
contains two BUG_ON(addr & 0x3) assertions
that verify fence writeback addresses are
dword-aligned. These assertions can be reached
from unprivileged userspace via crafted
DRM_IOCTL_AMDGPU_CS submissions, causing a fatal
kernel panic in a scheduler worker thread. Replace
both BUG_ON() calls with WARN_ON() to log the
condition without crashing the kernel. A
misaligned fence address at this point indicates a
driver bug, but crashing the kernel is never the
correct response when the assertion is reachable
from userspace. The CS IOCTL path is the correct
place to filter invalid submissions; the ring
emission callback is too late to do anything about
it. (cherry picked from commit
b90250bd933afd1ba94d86d6b13821997b22b18e) |
| CVE-2026-46225 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
rspi: fix controller deregistration Make sure to
deregister the controller before releasing
underlying resources like DMA during driver
unbind. |
| CVE-2026-46226 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
fsl: fix controller deregistration Make sure to
deregister the controller before releasing
underlying resources like DMA during driver
unbind. |
| CVE-2026-46227 |
In the Linux kernel, the
following vulnerability has been resolved: sctp:
revalidate list cursor after
sctp_sendmsg_to_asoc() in SCTP_SENDALL The
SCTP_SENDALL path in sctp_sendmsg() iterates
ep->asocs with list_for_each_entry_safe(),
which caches the next entry in @tmp before the
loop body runs. The body calls
sctp_sendmsg_to_asoc(), which may drop the socket
lock inside sctp_wait_for_sndbuf(). While the lock
is dropped, another thread can
SCTP_SOCKOPT_PEELOFF the association cached in
@tmp, migrating it to a new endpoint via
sctp_sock_migrate() (list_del_init() +
list_add_tail() to newep->asocs), and
optionally close the new socket which frees the
association via kfree_rcu(). The cached @tmp can
also be freed by a network ABORT for that
association, processed in softirq while the lock
is dropped. sctp_wait_for_sndbuf() revalidates
@asoc (the current entry) on re-lock via the "sk
!= asoc->base.sk" and "asoc->base.dead"
checks, but nothing revalidates @tmp. After a
successful return, the iterator advances to the
stale @tmp, yielding either a use-after-free (if
the peeled socket was closed) or a list-walk onto
the new endpoint's list head (type confusion of
&newep->asocs as a struct sctp_association
*). Both are reachable from CapEff=0; the
type-confusion path gives controlled indirect call
via the outqueue.sched->init_sid pointer. Fix
by re-deriving @tmp from @asoc after
sctp_sendmsg_to_asoc() returns. @asoc is known to
still be on ep->asocs at that point: the only
callers that list_del an association from
ep->asocs are sctp_association_free() (which
sets asoc->base.dead) and sctp_assoc_migrate()
(which changes asoc->base.sk), and
sctp_wait_for_sndbuf() checks both under the lock
before any successful return; a tripped check
propagates as err < 0 and the loop bails before
the re-derive. The SCTP_ABORT path in
sctp_sendmsg_check_sflags() returns 0 and the loop
hits 'continue' before sctp_sendmsg_to_asoc() is
ever called, so the @tmp cached by
list_for_each_entry_safe() still covers the
lock-held free that ba59fb027307 ("sctp: walk the
list of asoc safely") was added for. |
| CVE-2026-46229 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdkfd: Clear VRAM on allocation to prevent
stale data exposure KFD VRAM allocations set
AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE but not
AMDGPU_GEM_CREATE_VRAM_CLEARED, leaving freshly
allocated VRAM with stale data from prior use
observable by compute kernels. The GEM ioctl path
already sets VRAM_CLEARED for all userspace
allocations via amdgpu_gem_create_ioctl() and
amdgpu_mode_dumb_create(). The KFD path was
missing this flag, allowing stale page table
remnants to leak into user buffers. This causes
crashes in RCCL P2P transport where non-zero data
in ptrExchange/head/tail fields corrupts the
protocol handshake. |
| CVE-2026-46230 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amdgpu/vcn3: Prevent OOB reads when parsing
dec msg Check bounds against the end of the BO
whenever we access the msg. |
| CVE-2026-46231 |
In the Linux kernel, the
following vulnerability has been resolved:
batman-adv: bla: put backbone reference on failed
claim hash insert When batadv_bla_add_claim()
fails to insert a new claim into the hash, it
leaked a reference to the backbone_gw for which
the claim was intended. Call
batadv_backbone_gw_put() on the error path to
release the reference and avoid leaking the
backbone_gw object. |
| CVE-2026-46232 |
In the Linux kernel, the
following vulnerability has been resolved: HID:
playstation: Clamp num_touch_reports A device
would never lie about the number of touch reports
would it? If it does the loop in
dualshock4_parse_report will read off the end of
the touch_reports array, up to about 2 KiB for the
maximum number of 256 loop iteraions. The data
that is read is emitted via evdev if the
DS4_TOUCH_POINT_INACTIVE bit happens to be set.
Protect against this by clamping the
num_touch_reports value provided by the device to
the maximum size of the touch_reports
array. |
| CVE-2026-46233 |
In the Linux kernel, the
following vulnerability has been resolved:
batman-adv: bla: only purge non-released claims
When batadv_bla_purge_claims() goes through the
list of claims, it is only traversing the hash
list with an rcu_read_lock(). Due to a potential
parallel batadv_claim_put(), it can happen that it
encounters a claim which was actually in the
process of being released+freed by
batadv_claim_release(). In this case, backbone_gw
is set to NULL before the delayed RCU kfree is
started. Calling
batadv_bla_claim_get_backbone_gw() is then no
longer allowed because it would cause a NULL-ptr
derefence. To avoid this, only claims with a valid
reference counter must be purged. All others are
already taken care of. |
| CVE-2026-46234 |
In the Linux kernel, the
following vulnerability has been resolved: vsock:
fix buffer size clamping order In
vsock_update_buffer_size(), the buffer size was
being clamped to the maximum first, and then to
the minimum. If a user sets a minimum buffer size
larger than the maximum, the minimum check
overrides the maximum check, inverting the
constraint. This breaks the intended socket memory
boundaries by allowing the vsk->buffer_size to
grow beyond the configured
vsk->buffer_max_size. Fix this by checking the
minimum first, and then the maximum. This ensures
the buffer size never exceeds the
buffer_max_size. |
| CVE-2026-46235 |
In the Linux kernel, the
following vulnerability has been resolved: media:
saa7164: add ioremap return checks and cleanups
Add checks for ioremap return values in
saa7164_dev_setup(). If ioremap for BAR0 or BAR2
fails, release the already allocated PCI memory
regions, remove the device from the global list,
decrement the device count, and return -ENODEV.
This prevents potential null pointer dereferences
and ensures proper cleanup on memory mapping
failures. |
| CVE-2026-46236 |
In the Linux kernel, the
following vulnerability has been resolved: media:
rc: xbox_remote: heed DMA restrictions The buffer
for IO must not be part of the device structure
because that violates the DMA coherency
rules. |
| CVE-2026-46238 |
In the Linux kernel, the
following vulnerability has been resolved:
batman-adv: stop caching unowned originator
pointers in BAT IV BAT IV keeps the last-hop
neighbor address in each neigh_node, but some
paths also cache an originator pointer derived
from a temporary lookup. That pointer is not owned
by the neigh_node and may no longer refer to a
live originator entry after purge handling runs.
Stop storing the auxiliary originator pointer in
the BAT IV neighbor state. When BAT IV needs the
neighbor originator data, resolve it from the
stored neighbor address and drop the reference
again after use. [sven: avoid bonding logic for
outgoing OGM] |
| CVE-2026-46241 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
mpc52xx: fix use-after-free on registration
failure Make sure to disable and free the
interrupts in case controller registration fails
to avoid a potential use-after-free and resource
leak. This issue was flagged by Sashiko when
reviewing a controller deregistration fix. |
| CVE-2026-46242 |
In the Linux kernel, the
following vulnerability has been resolved:
eventpoll: fix ep_remove struct eventpoll / struct
file UAF ep_remove() (via ep_remove_file())
cleared file->f_ep under file->f_lock but
then kept using @file inside the critical section
(is_file_epoll(), hlist_del_rcu() through the
head, spin_unlock). A concurrent __fput() taking
the eventpoll_release() fastpath in that window
observed the transient NULL, skipped
eventpoll_release_file() and ran to
f_op->release / file_free(). For the
epoll-watches-epoll case, f_op->release is
ep_eventpoll_release() -> ep_clear_and_put()
-> ep_free(), which kfree()s the watched struct
eventpoll. Its embedded ->refs hlist_head is
exactly where epi->fllink.pprev points, so the
subsequent hlist_del_rcu()'s "*pprev = next"
scribbles into freed kmalloc-192 memory. In
addition, struct file is SLAB_TYPESAFE_BY_RCU, so
the slot backing @file could be recycled by
alloc_empty_file() -- reinitializing f_lock and
f_ep -- while ep_remove() is still nominally
inside that lock. The upshot is an
attacker-controllable kmem_cache_free() against
the wrong slab cache. Pin @file via epi_fget() at
the top of ep_remove() and gate the critical
section on the pin succeeding. With the pin held
@file cannot reach refcount zero, which holds
__fput() off and transitively keeps the watched
struct eventpoll alive across the hlist_del_rcu()
and the f_lock use, closing both UAFs. If the pin
fails @file has already reached refcount zero and
its __fput() is in flight. Because we bailed
before clearing f_ep, that path takes the
eventpoll_release() slow path into
eventpoll_release_file() and blocks on ep->mtx
until the waiter side's ep_clear_and_put() drops
it. The bailed epi's share of ep->refcount
stays intact, so the trailing
ep_refcount_dec_and_test() in ep_clear_and_put()
cannot free the eventpoll out from under
eventpoll_release_file(); the orphaned epi is then
cleaned up there. A successful pin also proves we
are not racing eventpoll_release_file() on this
epi, so drop the now-redundant re-check of
epi->dying under f_lock. The cheap lockless
READ_ONCE(epi->dying) fast-path bailout
stays. |
| CVE-2026-46244 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nft_inner: Fix IPv6 inner_thoff desync
In nft_inner_parse_l2l3(), when processing inner
IPv6 packets, ipv6_find_hdr() correctly computes
the transport header offset traversing all
extension headers, but the result is immediately
overwritten with nhoff + sizeof(_ip6h) (40 bytes),
which only accounts for the IPv6 base header. This
creates a desync between inner_thoff (wrong —
points to extension header start) and l4proto
(correct — e.g., IPPROTO_TCP), enabling transport
header forgery and potential firewall bypass. This
issue affects stable versions from Linux 6.2. For
comparison, the normal (non-inner) IPv6 path
correctly preserves ipv6_find_hdr()'s result.
Removing the incorrect overwrite ensures that
ipv6_find_hdr()'s calculated transport header
offset is preserved, thereby fixing the
desynchronization. |
| CVE-2026-46245 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/amd/display: Fix dc_link NULL handling in HPD
init amdgpu_dm_hpd_init() may see connectors
without a valid dc_link. The code already checks
dc_link for the polling decision, but later
unconditionally dereferences it when setting up
HPD interrupts. Assign dc_link early and skip
connectors where it is NULL. Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940
amdgpu_dm_hpd_init() error: we previously assumed
'dc_link' could be null (see line 931)
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c
923 /* 924 * Analog connectors may be hot-plugged
unlike other connector 925 * types that don't
support HPD. Only poll analog connectors. 926 */
927 use_polling |= 928
amdgpu_dm_connector->dc_link &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this
NULL check but hopefully it can be removed 929
dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id);
930 931 dc_link = amdgpu_dm_connector->dc_link;
dc_link assigned here. 932 933 /* 934 * Get a base
driver irq reference for hpd ints for the lifetime
935 * of dm. Note that only hpd interrupt types
are registered with 936 * base driver; hpd_rx
types aren't. IOW, amdgpu_irq_get/put on 937 *
hpd_rx isn't available. DM currently controls
hpd_rx 938 * explicitly with dc_interrupt_set()
939 */ --> 940 if (dc_link->irq_source_hpd
!= DC_IRQ_SOURCE_INVALID) {
^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are
trouble because we dereference it here. 941
irq_type = dc_link->irq_source_hpd -
DC_IRQ_SOURCE_HPD1; 942 /* 943 * TODO: There's a
mismatch between mode_info.num_hpd 944 * and what
bios reports as the # of connectors with
hpd |
| CVE-2026-46252 |
In the Linux kernel, the
following vulnerability has been resolved:
regulator: core: fix locking in
regulator_resolve_supply() error path If late
enabling of a supply regulator fails in
regulator_resolve_supply(), the code currently
triggers a lockdep warning: WARNING:
drivers/regulator/core.c:2649 at
_regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596
... Call trace: _regulator_put+0x80/0xa0 (P)
regulator_resolve_supply+0x7cc/0xbe0
regulator_register_resolve_supply+0x28/0xb8 as the
regulator_list_mutex must be held when calling
_regulator_put(). To solve this, simply switch to
using regulator_put(). While at it, we should also
make sure that no concurrent access happens to our
rdev while we clear out the supply pointer. Add
appropriate locking to ensure that. While the code
in question will be removed altogether in a
follow-up commit, I believe it is still beneficial
to have this corrected before removal for future
reference. |
| CVE-2026-46272 |
In the Linux kernel, the
following vulnerability has been resolved:
coresight: tmc-etr: Fix race condition between
sysfs and perf mode When trying to run perf and
sysfs mode simultaneously, the WARN_ON() in
tmc_etr_enable_hw() is triggered sometimes:
WARNING: CPU: 42 PID: 3911571 at
drivers/hwtracing/coresight/coresight-tmc-etr.c:1060
tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc]
[..snip..] Call trace: tmc_etr_enable_hw+0xc0/0xd8
[coresight_tmc] (P)
tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc]
(L) tmc_enable_etr_sink+0x11c/0x250
[coresight_tmc] coresight_enable_path+0x1c8/0x218
[coresight] coresight_enable_sysfs+0xa4/0x228
[coresight] enable_source_store+0x58/0xa8
[coresight] dev_attr_store+0x20/0x40
sysfs_kf_write+0x4c/0x68
kernfs_fop_write_iter+0x120/0x1b8
vfs_write+0x2c8/0x388 ksys_write+0x74/0x108
__arm64_sys_write+0x24/0x38
el0_svc_common.constprop.0+0x64/0x148
do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130
el0t_64_sync_handler+0xc8/0xd0
el0t_64_sync+0x1ac/0x1b0 ---[ end trace
0000000000000000 ]--- Since the enablement of
sysfs mode is separeted into two critical regions,
one for sysfs buffer allocation and another for
hardware enablement, it's possible to race with
the perf mode. Fix this by double check whether
the perf mode's been used before enabling the
hardware in sysfs mode. mode: [sysfs mode] [perf
mode] tmc_etr_get_sysfs_buffer()
spin_lock(&drvdata->spinlock) [sysfs buffer
allocation] spin_unlock(&drvdata->spinlock)
spin_lock(&drvdata->spinlock)
tmc_etr_enable_hw() drvdata->etr_buf =
etr_perf->etr_buf
spin_unlock(&drvdata->spinlock)
spin_lock(&drvdata->spinlock)
tmc_etr_enable_hw() WARN_ON(drvdata->etr_buf)
// WARN sicne etr_buf initialized at the perf side
spin_unlock(&drvdata->spinlock) With this
fix, we retain the check for CS_MODE_PERF in
get_etr_sysfs_buf. This ensures we verify whether
the perf mode's already running before we actually
allocate the buffer. Then we can save the time of
allocating/freeing the sysfs buffer if race with
the perf mode. |
| CVE-2026-46273 |
In the Linux kernel, the
following vulnerability has been resolved:
ibmveth: Disable GSO for packets with small MSS
Some physical adapters on Power systems do not
support segmentation offload when the MSS is less
than 224 bytes. Attempting to send such packets
causes the adapter to freeze, stopping all traffic
until manually reset. Implement ndo_features_check
to disable GSO for packets with small MSS values.
The network stack will perform software
segmentation instead. The 224-byte minimum matches
ibmvnic commit <f10b09ef687f> ("ibmvnic:
Enforce stronger sanity checks on GSO packets")
which uses the same physical adapters in SEA
configurations. The issue occurs specifically when
the hardware attempts to perform segmentation
(gso_segs > 1) with a small MSS. Single-segment
GSO packets (gso_segs == 1) do not trigger the
problematic LSO code path and are transmitted
normally without segmentation. Add an
ndo_features_check callback to disable GSO when
MSS < 224 bytes. Also call
vlan_features_check() to ensure proper handling of
VLAN packets, particularly QinQ (802.1ad)
configurations where the hardware parser may not
support certain offload features. Validated using
iptables to force small MSS values. Without the
fix, the adapter freezes. With the fix, packets
are segmented in software and transmission
succeeds. Comprehensive regression testing
completedd (MSS tests, performance,
stability). |
| CVE-2026-46274 |
In the Linux kernel, the
following vulnerability has been resolved: io-wq:
check that the predecessor is hashed in
io_wq_remove_pending() io_wq_remove_pending()
needs to fix up wq->hash_tail[] if the
cancelled work was the tail of its hash bucket.
When doing this, it checks whether the preceding
entry in acct->work_list has the same hash
value, but never checks that the predecessor is
hashed at all. io_get_work_hash() is simply
atomic_read(&work->flags) >>
IO_WQ_HASH_SHIFT, and the hash bits are never set
for non-hashed work, so it returns 0. Thus, when a
hashed bucket-0 work is cancelled while a
non-hashed work is its list predecessor, the check
spuriously passes and a pointer to the non-hashed
io_kiocb is stored in wq->hash_tail[0]. Because
non-hashed work is dequeued via the fast path in
io_get_next_work(), which never touches
hash_tail[], the stale pointer is never cleared.
Therefore, after the non-hashed io_kiocb completes
and is freed back to req_cachep,
wq->hash_tail[0] is a dangling pointer. The
io_wq is per-task (tctx->io_wq) and survives
ring open/close, so the dangling pointer persists
for the lifetime of the task; the next hashed
bucket-0 enqueue dereferences it in
io_wq_insert_work() and wq_list_add_after() writes
through freed memory. Add the missing
io_wq_is_hashed() check so a non-hashed
predecessor never inherits a hash_tail[]
slot. |
| CVE-2026-46275 |
In the Linux kernel, the
following vulnerability has been resolved:
Bluetooth: hci_uart: fix UAFs and race conditions
in close and init paths Vulnerabilities leading to
Use-After-Free (UAF) and Null Pointer Dereference
(NPD) conditions were observed in the lifecycle
management of hci_uart. The primary issue arises
because the workqueues (init_ready and write_work)
are only flushed/cancelled if the
HCI_UART_PROTO_READY flag is set during TTY close.
If a hangup occurs before setup completes,
hci_uart_tty_close() skips the teardown of these
workqueues and proceeds to free the `hu` struct.
When the scheduled work executes later, it blindly
dereferences the freed `hu` struct. Furthermore,
several data races and UAFs were identified in the
teardown sequence: 1. Calling hci_uart_flush()
from hci_uart_close() without effectively
disabling write_work causes a race condition where
both can concurrently double-free hu->tx_skb.
This happens because protocol timers can
concurrently invoke hci_uart_tx_wakeup() and
requeue write_work. 2. Calling hci_free_dev(hdev)
before hu->proto->close(hu) causes a UAF
when vendor specific protocol close callbacks
dereference hu->hdev. 3. In the initialization
error paths, failing to take the proto_lock write
lock before clearing PROTO_READY leads to races
with active readers. Additionally,
hci_uart_tty_receive() accesses hu->hdev
outside the read lock, leading to UAFs if the
initialization error path frees hdev concurrently.
Fix these synchronization and lifecycle issues by:
1. Re-ordering hci_uart_tty_close() to clear
HCI_UART_PROTO_READY first, followed immediately
by a cancel_work_sync(&hu->write_work).
Clearing the flag locks out concurrent protocol
timers from successfully invoking
hci_uart_tx_wakeup(), effectively rendering the
cancellation permanent and preventing the tx_skb
double-free. 2. Note: Clearing PROTO_READY early
causes hci_uart_close() to skip
hu->proto->flush(). This is perfectly safe
in the tty_close path because
hu->proto->close() executes shortly after,
which intrinsically purges all protocol SKB queues
and tears down the state. 3. Relocating
hu->proto->close(hu) strictly prior to
hci_free_dev(hdev) across all close and error
paths to prevent vendor-level UAFs. 4. Moving the
hdev->stat.byte_rx increment in
hci_uart_tty_receive() inside the proto_lock
read-side critical section to safely synchronize
with device unregistration. 5. Adding
cancel_work_sync(&hu->write_work) to
hci_uart_close() to safely flush the workqueue
before hci_uart_flush() is invoked via the HCI
core. 6. Utilizing cancel_work_sync() instead of
disable_work_sync() across all paths to prevent
permanently breaking user-space retry
capabilities. |
| CVE-2026-46280 |
In the Linux kernel, the
following vulnerability has been resolved: lib:
test_hmm: evict device pages on file close to
avoid use-after-free Patch series "Minor hmm_test
fixes and cleanups". Two bugfixes a cleanup for
the HMM kernel selftests. These were mostly
reported by Zenghui Yu with special thanks to
Lorenzo for analysing and pointing out the
problems. This patch (of 3): When
dmirror_fops_release() is called it frees the
dmirror struct but doesn't migrate device private
pages back to system memory first. This leaves
those pages with a dangling zone_device_data
pointer to the freed dmirror. If a subsequent
fault occurs on those pages (eg. during coredump)
the dmirror_devmem_fault() callback dereferences
the stale pointer causing a kernel panic. This was
reported [1] when running mm/ksft_hmm.sh on arm64,
where a test failure triggered SIGABRT and the
resulting coredump walked the VMAs faulting in the
stale device private pages. Fix this by calling
dmirror_device_evict_chunk() for each devmem chunk
in dmirror_fops_release() to migrate all device
private pages back to system memory before freeing
the dmirror struct. The function is moved earlier
in the file to avoid a forward
declaration. |
| CVE-2026-46282 |
In the Linux kernel, the
following vulnerability has been resolved: iio:
frequency: admv1013: fix NULL pointer dereference
on str When device_property_read_string() fails,
str is left uninitialized but the code falls
through to strcmp(str, ...), dereferencing a
garbage pointer. Replace manual read/strcmp with
device_property_match_property_string() and
consolidate the SE mode enums into a single
sequential enum, mapping to hardware register
values via a switch consistent with other
bitfields in the driver. Several cleanup patches
have been applied to this driver recently so this
will need a manual backport. |
| CVE-2026-46285 |
In the Linux kernel, the
following vulnerability has been resolved: mtd:
docg3: fix use-after-free in docg3_release() In
docg3_release(), the docg3 pointer is obtained
from cascade->floors[0]->priv before the
loop that calls doc_release_device() on each
floor. doc_release_device() frees the docg3 struct
via kfree(docg3) at line 1881. After the loop,
docg3->cascade->bch dereferences the
already-freed pointer. Fix this by accessing
cascade->bch directly, which is equivalent
since docg3->cascade points back to the same
cascade struct, and is already available as a
local variable. This also removes the now-unused
docg3 local variable. |
| CVE-2026-46286 |
In the Linux kernel, the
following vulnerability has been resolved: leds:
qcom-lpg: Check for array overflow when selecting
the high resolution When selecting the high
resolution values from the array, FIELD_GET() is
used to pull from a 3 bit register, yet the array
being indexed has only 5 values in it. Odds are
the hardware is sane, but just to be safe,
properly check before just overflowing and reading
random data and then setting up chip values based
on that. |
| CVE-2026-46287 |
In the Linux kernel, the
following vulnerability has been resolved: net:
txgbe: fix RTNL assertion warning when remove
module For the copper NIC with external PHY, the
driver called phylink_connect_phy() during probe
and phylink_disconnect_phy() during remove. It
caused an RTNL assertion warning in
phylink_disconnect_phy() upon module remove. To
fix this, add rtnl_lock() and rtnl_unlock() around
the phylink_disconnect_phy() in remove function.
------------[ cut here ]------------ RTNL:
assertion failed at drivers/net/phy/phylink.c
(2351) WARNING: drivers/net/phy/phylink.c:2351 at
phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0:
rmmod/4464 Modules linked in: ... CPU: 0 UID: 0
PID: 4464 Comm: rmmod Kdump: loaded Not tainted
7.0.0-rc4+ Hardware name: Micro-Star International
Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI
(MS-7E16), BIOS 1.90 12/31/2024 RIP:
0010:phylink_disconnect_phy+0xe4/0xf0 [phylink]
Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31
f6 31 ff e9 3a 38 8f e7 48 8d 3d 48 87 e2 ff ba 2f
09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9
3a e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90
90 RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX:
0000000000000000 RDX: 000000000000092f RSI:
ffffffffc02422c1 RDI: ffffffffc0239020 RBP:
ffffce7288363ae8 R08: 0000000000000000 R09:
0000000000000000 R10: 0000000000000000 R11:
0000000000000000 R12: ffff8964c4022000 R13:
ffff89654fce3028 R14: ffff89654ebb4000 R15:
ffffffffc0226348 FS: 0000795e80d93780(0000)
GS:ffff896c52857000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4:
0000000000f50ef0 PKRU: 55555554 Call Trace:
<TASK> txgbe_remove_phy+0xbb/0xd0 [txgbe]
txgbe_remove+0x4c/0xb0 [txgbe]
pci_device_remove+0x41/0xb0
device_remove+0x43/0x80
device_release_driver_internal+0x206/0x270
driver_detach+0x4a/0xa0
bus_remove_driver+0x83/0x120
driver_unregister+0x2f/0x60
pci_unregister_driver+0x40/0x90
txgbe_driver_exit+0x10/0x850 [txgbe]
__do_sys_delete_module.isra.0+0x1c3/0x2f0
__x64_sys_delete_module+0x12/0x20
x64_sys_call+0x20c3/0x2390
do_syscall_64+0x11c/0x1500 ?
srso_alias_return_thunk+0x5/0xfbef5 ?
do_syscall_64+0x15a/0x1500 ?
srso_alias_return_thunk+0x5/0xfbef5 ?
do_fault+0x312/0x580 ?
srso_alias_return_thunk+0x5/0xfbef5 ?
__handle_mm_fault+0x9d5/0x1040 ?
srso_alias_return_thunk+0x5/0xfbef5 ?
count_memcg_events+0x101/0x1d0 ?
srso_alias_return_thunk+0x5/0xfbef5 ?
handle_mm_fault+0x1e8/0x2f0 ?
srso_alias_return_thunk+0x5/0xfbef5 ?
do_user_addr_fault+0x2f8/0x820 ?
srso_alias_return_thunk+0x5/0xfbef5 ?
irqentry_exit+0xb2/0x600 ?
srso_alias_return_thunk+0x5/0xfbef5 ?
exc_page_fault+0x92/0x1c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e |
| CVE-2026-46289 |
In the Linux kernel, the
following vulnerability has been resolved:
lib/scatterlist: fix length calculations in
extract_kvec_to_sg Patch series "Fix bugs in
extract_iter_to_sg()", v3. Fix bugs in the kvec
and user variants of extract_iter_to_sg. This
series is growing due to useful remarks made by
sashiko.dev. The main bugs are: - The length for
an sglist entry when extracting from a kvec can
exceed the number of bytes in the page. This is
obviously not intended. - When extracting a user
buffer the sglist is temporarily used as a scratch
buffer for extracted page pointers. If the sglist
already contains some elements this scratch buffer
could overlap with existing entries in the sglist.
The series adds test cases to the kunit_iov_iter
test that demonstrate all of these bugs.
Additionally, there is a memory leak fix for the
test itself. The bugs were orignally introduced
into kernel v6.3 where the function lived in
fs/netfs/iterator.c. It was later moved to
lib/scatterlist.c in v6.5. Thus the actual fix is
only marked for backports to v6.5+. This patch (of
5): When extracting from a kvec to a scatterlist,
do not cross page boundaries. The required length
was already calculated but not used as intended.
Adjust the copied length if the loop runs out of
sglist entries without extracting everything.
While there, return immediately from
extract_iter_to_sg if there are no sglist entries
at all. A subsequent commit will add kunit test
cases that demonstrate that the patch is
necessary. |
| CVE-2026-46291 |
In the Linux kernel, the
following vulnerability has been resolved: crypto:
caam - guard HMAC key hex dumps in hash_digest_key
Use print_hex_dump_devel() for dumping sensitive
HMAC key bytes in hash_digest_key() to avoid
leaking secrets at runtime when
CONFIG_DYNAMIC_DEBUG is enabled. |
| CVE-2026-46292 |
In the Linux kernel, the
following vulnerability has been resolved:
pmdomain: core: Fix detach procedure for virtual
devices in genpd If a device is attached to a PM
domain through genpd_dev_pm_attach_by_id(), genpd
calls pm_runtime_enable() for the corresponding
virtual device that it registers. While this
avoids boilerplate code in drivers, there is no
corresponding call to pm_runtime_disable() in
genpd_dev_pm_detach(). This means these virtual
devices are typically detached from its genpd,
while runtime PM remains enabled for them, which
is not how things are designed to work. In worst
cases it may lead to critical errors, like a NULL
pointer dereference bug in
genpd_runtime_suspend(), which was recently
reported. For another case, we may end up keeping
an unnecessary vote for a performance state for
the device. To fix these problems, let's add this
missing call to pm_runtime_disable() in
genpd_dev_pm_detach(). |
| CVE-2026-46293 |
In the Linux kernel, the
following vulnerability has been resolved: clk:
microchip: mpfs-ccc: fix out of bounds access
during output registration UBSAN reported an out
of bounds access during registration of the last
two outputs. This out of bounds access occurs
because space is only allocated in the hws array
for two PLLs and the four output dividers that
each has, but the defined IDs contain two DLLS and
their two outputs each, which are not supported by
the driver. The ID order is PLLs -> DLLs ->
PLL outputs -> DLL outputs. Decrement the PLL
output IDs by two while adding them to the array
to avoid the problem. |
| CVE-2026-46294 |
In the Linux kernel, the
following vulnerability has been resolved: dm: fix
a buffer overflow in ioctl processing Tony Asleson
(using Claude) found a buffer overflow in dm-ioctl
in the function retrieve_status: 1. The code in
retrieve_status checks that the output string fits
into the output buffer and writes the output
string there 2. Then, the code aligns the "outptr"
variable to the next 8-byte boundary: outptr =
align_ptr(outptr); 3. The alignment doesn't check
overflow, so outptr could point past the buffer
end 4. The "for" loop is iterated again, it
executes: remaining = len - (outptr - outbuf); 5.
If "outptr" points past "outbuf + len", the
arithmetics wraps around and the variable
"remaining" contains unusually high number 6. With
"remaining" being high, the code writes more data
past the end of the buffer Luckily, this bug has
no security implications because: 1. Only root can
issue device mapper ioctls 2. The commonly used
libraries that communicate with device mapper
(libdevmapper and devicemapper-rs) use buffer size
that is aligned to 8 bytes - thus, "outptr =
align_ptr(outptr)" can't overshoot the input
buffer and the bug can't happen
accidentally |
| CVE-2026-46296 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
s3c64xx: fix NULL-deref on driver unbind A change
moving DMA channel allocation from probe() back to
s3c64xx_spi_prepare_transfer() failed to remove
the corresponding deallocation from remove(). Drop
the bogus DMA channel release from remove() to
avoid triggering a NULL-pointer dereference on
driver unbind. This issue was flagged by Sashiko
when reviewing a controller deregistration
fix. |
| CVE-2026-46299 |
In the Linux kernel, the
following vulnerability has been resolved:
hfsplus: fix held lock freed on
hfsplus_fill_super() hfsplus_fill_super() calls
hfs_find_init() to initialize a search structure,
which acquires tree->tree_lock. If the
subsequent call to hfsplus_cat_build_key() fails,
the function jumps to the out_put_root error label
without releasing the lock. The later cleanup path
then frees the tree data structure with the lock
still held, triggering a held lock freed warning.
Fix this by adding the missing
hfs_find_exit(&fd) call before jumping to the
out_put_root error label. This ensures that
tree->tree_lock is properly released on the
error path. The bug was originally detected on
v6.13-rc1 using an experimental static analysis
tool we are developing, and we have verified that
the issue persists in the latest mainline kernel.
The tool is specifically designed to detect memory
management issues. It is currently under active
development and not yet publicly available. We
confirmed the bug by runtime testing under QEMU
with x86_64 defconfig, lockdep enabled, and
CONFIG_HFSPLUS_FS=y. To trigger the error path, we
used GDB to dynamically shrink the max_unistr_len
parameter to 1 before hfsplus_asc2uni() is called.
This forces hfsplus_asc2uni() to naturally return
-ENAMETOOLONG, which propagates to
hfsplus_cat_build_key() and exercises the faulty
error path. The following warning was observed
during mount: ========================= WARNING:
held lock freed! 7.0.0-rc3-00016-gb4f0dd314b39 #4
Not tainted ------------------------- mount/174 is
freeing memory ffff888103f92000-ffff888103f92fff,
with a lock still held there! ffff888103f920b0
(&tree->tree_lock){+.+.}-{4:4}, at:
hfsplus_find_init+0x154/0x1e0 2 locks held by
mount/174: #0: ffff888103f960e0
(&type->s_umount_key#42/1){+.+.}-{4:4}, at:
alloc_super.constprop.0+0x167/0xa40 #1:
ffff888103f920b0
(&tree->tree_lock){+.+.}-{4:4}, at:
hfsplus_find_init+0x154/0x1e0 stack backtrace:
CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted
7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9,
2009), BIOS 1.15.0-1 04/01/2014 Call Trace:
<TASK> dump_stack_lvl+0x82/0xd0
debug_check_no_locks_freed+0x13a/0x180
kfree+0x16b/0x510 ?
hfsplus_fill_super+0xcb4/0x18a0
hfsplus_fill_super+0xcb4/0x18a0 ?
__pfx_hfsplus_fill_super+0x10/0x10 ?
srso_return_thunk+0x5/0x5f ? bdev_open+0x65f/0xc30
? srso_return_thunk+0x5/0x5f ? pointer+0x4ce/0xbf0
? trace_contention_end+0x11c/0x150 ?
__pfx_pointer+0x10/0x10 ?
srso_return_thunk+0x5/0x5f ? bdev_open+0x79b/0xc30
? srso_return_thunk+0x5/0x5f ?
srso_return_thunk+0x5/0x5f ?
vsnprintf+0x6da/0x1270 ?
srso_return_thunk+0x5/0x5f ?
__mutex_unlock_slowpath+0x157/0x740 ?
__pfx_vsnprintf+0x10/0x10 ?
srso_return_thunk+0x5/0x5f ?
srso_return_thunk+0x5/0x5f ?
mark_held_locks+0x49/0x80 ?
srso_return_thunk+0x5/0x5f ?
srso_return_thunk+0x5/0x5f ?
irqentry_exit+0x17b/0x5e0 ?
trace_irq_disable.constprop.0+0x116/0x150 ?
__pfx_hfsplus_fill_super+0x10/0x10 ?
__pfx_hfsplus_fill_super+0x10/0x10
get_tree_bdev_flags+0x302/0x580 ?
__pfx_get_tree_bdev_flags+0x10/0x10 ?
vfs_parse_fs_qstr+0x129/0x1a0 ?
__pfx_vfs_parse_fs_qstr+0x3/0x10
vfs_get_tree+0x89/0x320 fc_mount+0x10/0x1d0
path_mount+0x5c5/0x21c0 ?
__pfx_path_mount+0x10/0x10 ?
trace_irq_enable.constprop.0+0x116/0x150 ?
trace_irq_enable.constprop.0+0x116/0x150 ?
srso_return_thunk+0x5/0x5f ?
srso_return_thunk+0x5/0x5f ?
kmem_cache_free+0x307/0x540 ?
user_path_at+0x51/0x60 ?
__x64_sys_mount+0x212/0x280 ?
srso_return_thunk+0x5/0x5f
__x64_sys_mount+0x212/0x280 ?
__pfx___x64_sys_mount+0x10/0x10 ?
srso_return_thunk+0x5/0x5f ?
trace_irq_enable.constprop.0+0x116/0x150 ?
srso_return_thunk+0x5/0x5f
do_syscall_64+0x111/0x680
entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP:
0033:0x7ffacad55eae Code: 48 8b 0d 85 1f 0f 00 f7
d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00
00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 RSP:
002b ---truncated--- |
| CVE-2026-46300 |
In the Linux kernel, the
following vulnerability has been resolved: net:
skbuff: preserve shared-frag marker during
coalescing skb_try_coalesce() can attach paged
frags from @from to @to. If @from has
SKBFL_SHARED_FRAG set, the resulting @to skb can
contain the same externally-owned or
page-cache-backed frags, but the shared-frag
marker is currently lost. That breaks the
invariant relied on by later in-place writers. In
particular, ESP input checks skb_has_shared_frag()
before deciding whether an uncloned nonlinear skb
can skip skb_cow_data(). If TCP receive coalescing
has moved shared frags into an unmarked skb, ESP
can see skb_has_shared_frag() as false and decrypt
in place over page-cache backed frags. Propagate
SKBFL_SHARED_FRAG when skb_try_coalesce()
transfers paged frags. The tailroom copy path does
not need the marker because it copies bytes into
@to's linear data rather than transferring frag
descriptors. |
| CVE-2026-46301 |
In the Linux kernel, the
following vulnerability has been resolved: spi:
topcliff-pch: fix use-after-free on unbind Give
the driver a chance to flush its queue before
releasing the DMA buffers on driver unbind |
| CVE-2026-46302 |
In the Linux kernel, the
following vulnerability has been resolved:
selinux: allow multiple opens of
/sys/fs/selinux/policy Currently there can only be
a single open of /sys/fs/selinux/policy at any
time. This allows any process to block any other
process from reading the kernel policy. The
original motivation seems to have been a mix of
preventing an inconsistent view of the policy size
and preventing userspace from allocating kernel
memory without bound, but this is arguably equally
bad. Eliminate the policy_opened flag and shrink
the critical section that the policy mutex is
held. While we are making changes here, drop a
couple of extraneous BUG_ONs. |
| CVE-2026-46303 |
In the Linux kernel, the
following vulnerability has been resolved: isofs:
validate Rock Ridge CE continuation extent against
volume size rock_continue() reads
rs->cont_extent verbatim from the Rock Ridge CE
record and passes it to sb_bread() without
checking that the block number is within the
mounted ISO 9660 volume. commit e595447e177b
("[PATCH] rock.c: handle corrupted directories")
added cont_offset and cont_size rejection for the
CE continuation but did not validate the extent
block number itself. commit f54e18f1b831 ("isofs:
Fix infinite looping over CE entries") later
capped the CE chain length at RR_MAX_CE_ENTRIES =
32 but again left the block number unchecked. With
a crafted ISO mounted via udisks2 (desktop optical
auto-mount) or via CAP_SYS_ADMIN mount,
rs->cont_extent can therefore point at an
out-of-range block or at blocks belonging to an
adjacent filesystem on the same block device.
sb_bread() on an out-of-range block returns NULL
cleanly via the block layer EIO path, so there is
no memory-safety violation. For in-range reads of
adjacent- filesystem data, the CE buffer is parsed
as Rock Ridge records and only the text of SL
sub-records reaches userspace through readlink(),
which makes the info-leak channel narrow and
difficult to exploit; still, rejecting the
malformed CE outright matches the rejection shape
already present in the same function for
cont_offset and cont_size. Add an
ISOFS_SB(sb)->s_nzones bounds check to
rock_continue() next to the existing offset/size
rejection, printing the same
corrupted-directory-entry notice. |
| CVE-2026-46304 |
In the Linux kernel, the
following vulnerability has been resolved: nvmet:
avoid recursive nvmet-wq flush in nvmet_ctrl_free
nvmet_tcp_release_queue_work() runs on nvmet-wq
and can drop the final controller reference
through nvmet_cq_put(). If that triggers
nvmet_ctrl_free(), the teardown path flushes
ctrl->async_event_work on the same nvmet-wq.
Call chain: nvmet_tcp_schedule_release_queue()
kref_put(&queue->kref,
nvmet_tcp_release_queue) nvmet_tcp_release_queue()
queue_work(nvmet_wq, &queue->release_work)
<--- nvmet_wq process_one_work()
nvmet_tcp_release_queue_work()
nvmet_cq_put(&queue->nvme_cq)
nvmet_cq_destroy() nvmet_ctrl_put(cq->ctrl)
nvmet_ctrl_free()
flush_work(&ctrl->async_event_work) <---
nvmet_wq Previously Scheduled by :-
nvmet_add_async_event queue_work(nvmet_wq,
&ctrl->async_event_work); This trips
lockdep with a possible recursive locking warning.
[ 5223.015876] run blktests nvme/003 at 2026-04-07
20:53:55 [ 5223.061801] loop0: detected capacity
change from 0 to 2097152 [ 5223.072206] nvmet:
adding nsid 1 to subsystem blktests-subsystem-1 [
5223.088368] nvmet_tcp: enabling port 0
(127.0.0.1:4420) [ 5223.126086] nvmet: Created
discovery controller 1 for subsystem
nqn.2014-08.org.nvmexpress.discovery for NQN
nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.
[ 5223.128453] nvme nvme1: new ctrl: NQN
"nqn.2014-08.org.nvmexpress.discovery", addr
127.0.0.1:4420, hostnqn:
nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349
[ 5233.199447] nvme nvme1: Removing ctrl: NQN
"nqn.2014-08.org.nvmexpress.discovery" [
5233.227718]
============================================ [
5233.231283] WARNING: possible recursive locking
detected [ 5233.234696] 7.0.0-rc3nvme+ #20
Tainted: G O N [ 5233.238434]
-------------------------------------------- [
5233.241852] kworker/u192:6/2413 is trying to
acquire lock: [ 5233.245429] ffff888111632548
((wq_completion)nvmet-wq){+.+.}-{0:0}, at:
touch_wq_lockdep_map+0x26/0x90 [ 5233.251438] but
task is already holding lock: [ 5233.255254]
ffff888111632548
((wq_completion)nvmet-wq){+.+.}-{0:0}, at:
process_one_work+0x5cc/0x6e0 [ 5233.261125] other
info that might help us debug this: [ 5233.265333]
Possible unsafe locking scenario: [ 5233.269217]
CPU0 [ 5233.270795] ---- [ 5233.272436]
lock((wq_completion)nvmet-wq); [ 5233.275241]
lock((wq_completion)nvmet-wq); [ 5233.278020] ***
DEADLOCK *** [ 5233.281793] May be due to missing
lock nesting notation [ 5233.286195] 3 locks held
by kworker/u192:6/2413: [ 5233.289192] #0:
ffff888111632548
((wq_completion)nvmet-wq){+.+.}-{0:0}, at:
process_one_work+0x5cc/0x6e0 [ 5233.294569] #1:
ffffc9000e2a7e40
((work_completion)(&queue->release_work)){+.+.}-{0:0},
at: process_one_work+0x1c5/0x6e0 [ 5233.300128]
#2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3},
at: __flush_work+0x62/0x530 [ 5233.304290] stack
backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413
Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+
#20 PREEMPT(full) [ 5233.306524] Tainted:
[O]=OOT_MODULE, [N]=TEST [ 5233.306525] Hardware
name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org
04/01/2014 [ 5233.306527] Workqueue: nvmet-wq
nvmet_tcp_release_queue_work [nvmet_tcp] [
5233.306532] Call Trace: [ 5233.306534]
<TASK> [ 5233.306536]
dump_stack_lvl+0x73/0xb0 [ 5233.306552]
print_deadlock_bug+0x225/0x2f0 [ 5233.306556]
__lock_acquire+0x13f0/0x2290 [ 5233.306563]
lock_acquire+0xd0/0x300 [ 5233.306565] ?
touch_wq_lockdep_map+0x26/0x90 [ 5233.306571] ?
__flush_work+0x20b/0x530 [ 5233.306573] ?
touch_wq_lockdep_map+0x26/0x90 [ 5233.306577]
touch_wq_lockdep_map+0x3b/0x90 [ 5233.306580] ?
touch_wq_lockdep_map+0x26/0x90 [ 52
---truncated--- |
| CVE-2026-46306 |
In the Linux kernel, the
following vulnerability has been resolved:
flow_dissector: do not dissect PPPoE PFC frames
RFC 2516 Section 7 states that Protocol Field
Compression (PFC) is NOT RECOMMENDED for PPPoE. In
practice, pppd does not support negotiating PFC
for PPPoE sessions, and the flow dissector driver
has assumed an uncompressed frame until the blamed
commit. During the review process of that commit
[1], support for PFC is suggested. However, having
a compressed (1-byte) protocol field means the
subsequent PPP payload is shifted by one byte,
causing 4-byte misalignment for the network header
and an unaligned access exception on some
architectures. The exception can be reproduced by
sending a PPPoE PFC frame to an ethernet interface
of a MIPS board, with RPS enabled, even if no
PPPoE session is active on that interface: $ 0 :
00000000 80c40000 00000000 85144817 $ 4 : 00000008
00000100 80a75758 81dc9bb8 $ 8 : 00000010 8087ae2c
0000003d 00000000 $12 : 000000e0 00000039 00000000
00000000 $16 : 85043240 80a75758 81dc9bb8 00006488
$20 : 0000002f 00000007 85144810 80a70000 $24 :
81d1bda0 00000000 $28 : 81dc8000 81dc9aa8 00000000
805ead08 Hi : 00009d51 Lo : 2163358a epc :
805e91f0 __skb_flow_dissect+0x1b0/0x1b50 ra :
805ead08 __skb_get_hash_net+0x74/0x12c Status:
11000403 KERNEL EXL IE Cause : 40800010 (ExcCode
04) BadVA : 85144817 PrId : 0001992f (MIPS 1004Kc)
Call Trace: [<805e91f0>]
__skb_flow_dissect+0x1b0/0x1b50 [<805ead08>]
__skb_get_hash_net+0x74/0x12c [<805ef330>]
get_rps_cpu+0x1b8/0x3fc [<805fca70>]
netif_receive_skb_list_internal+0x324/0x364
[<805fd120>] napi_complete_done+0x68/0x2a4
[<8058de5c>] mtk_napi_rx+0x228/0xfec
[<805fd398>] __napi_poll+0x3c/0x1c4
[<805fd754>]
napi_threaded_poll_loop+0x234/0x29c
[<805fd848>] napi_threaded_poll+0x8c/0xb0
[<80053544>] kthread+0x104/0x12c
[<80002bd8>]
ret_from_kernel_thread+0x14/0x1c Code: 02d51821
1060045b 00000000 <8c640000> 3084000f
2c820005 144001a2 00042080 8e220000 To reduce the
attack surface and maintain performance, do not
process PPPoE PFC frames. [1]
https://lore.kernel.org/r/20220630231016.GA392@debian.home |
| CVE-2026-46307 |
In the Linux kernel, the
following vulnerability has been resolved: wifi:
ath5k: do not access array OOB Vincent reports:
> The ath5k driver seems to do an
array-index-out-of-bounds access as > shown by
the UBSAN kernel message: > UBSAN:
array-index-out-of-bounds in
drivers/net/wireless/ath/ath5k/base.c:1741:20 >
index 4 is out of range for type
'ieee80211_tx_rate [4]' > ... > Call Trace:
> <TASK> > dump_stack_lvl+0x5d/0x80
> ubsan_epilogue+0x5/0x2b >
__ubsan_handle_out_of_bounds.cold+0x46/0x4b >
ath5k_tasklet_tx+0x4e0/0x560 [ath5k] >
tasklet_action_common+0xb5/0x1c0 It is real.
'ts->ts_final_idx' can be 3 on 5212, so:
info->status.rates[ts->ts_final_idx + 1].idx
= -1; with the array defined as: struct
ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];
while the size is: #define IEEE80211_TX_MAX_RATES
4 is indeed bogus. Set this 'idx = -1' sentinel
only if the array index is less than the array
size. As mac80211 will not look at rates beyond
the size (IEEE80211_TX_MAX_RATES). Note: The
effect of the OOB write is negligible. It just
overwrites the next member of info->status,
i.e. ack_signal. |
| CVE-2026-46312 |
In the Linux kernel, the
following vulnerability has been resolved: media:
videobuf2: Set vma_flags in vb2_dma_sg_mmap
vb2_dma_contig sets VMA flags VM_DONTEXPAND and
VM_DONTDUMP and I do not see a reason why
vb2_dma_sg should behave differently. This avoids
hitting `WARN_ON(!(vma->vm_flags &
VM_DONTEXPAND));` in drm_gem_mmap_obj() during
mmap() of an imported dma-buf from the out of tree
Apple ISP camera capture driver which uses
vb2_dma_sg_memops. gst-launch-1.0 v4l2src !
gtk4paintablesink [ 38.201528] ------------[ cut
here ]------------ [ 38.202135] WARNING: CPU: 7
PID: 2362 at drivers/gpu/drm/drm_gem.c:1144
drm_gem_mmap_obj+0x1f8/0x210 [ 38.203278] Modules
linked in: rfcomm snd_seq_dummy snd_hrtimer
snd_seq snd_seq_device uinput
nf_conntrack_netbios_ns nf_conntrack_broadcast
nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib
nft_reject_inet nf_reject_ipv6 nft_reject nft_ct
nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 nf_tables qrtr bnep nls_ascii
i2c_dev loop fuse dm_multipath nfnetlink
brcmfmac_wcc hid_magicmouse hci_bcm4377 brcmfmac
brcmutil bluetooth ecdh_generic cfg80211 ecc btrfs
xor xor_neon rfkill hid_apple raid6_pq joydev
aop_als apple_nvmem_spmi industrialio snd_soc_aop
apple_z2 snd_soc_cs42l84 tps6598x snd_soc_tas2764
macsmc_reboot spi_nor macsmc_hwmon rtc_macsmc
gpio_macsmc macsmc_power regmap_spmi macsmc_input
dockchannel_hid panel_summit appledrm nvme_apple
dwc3 snd_soc_macaudio drm_client_lib nvme_core
phy_apple_atc hwmon apple_sart apple_dockchannel
macsmc apple_rtkit_helper spmi_apple_controller
aop apple_wdt mfd_core nvmem_apple_efuses
pinctrl_apple_gpio apple_isp apple_dcp
videobuf2_dma_sg mux_core spi_apple [ 38.203300]
videobuf2_memops i2c_pasemi_platform
snd_soc_apple_mca videobuf2_v4l2 videodev
clk_apple_nco videobuf2_common snd_pcm_dmaengine
adpdrm asahi apple_admac adpdrm_mipi
drm_dma_helper pwm_apple i2c_pasemi_core
drm_display_helper mc cec apple_dart ofpart
apple_soc_cpufreq leds_pwm phram [ 38.217677] CPU:
7 UID: 1000 PID: 2362 Comm: gst-launch-1.0
Tainted: G W 6.17.6+ #asahi-dev PREEMPT(full) [
38.219040] Tainted: [W]=WARN [ 38.219398] Hardware
name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [
38.220213] pstate: 21400005 (nzCv daif +PAN -UAO
-TCO +DIT -SSBS BTYPE=--) [ 38.221088] pc :
drm_gem_mmap_obj+0x1f8/0x210 [ 38.221643] lr :
drm_gem_mmap_obj+0x78/0x210 [ 38.222178] sp :
ffffc0008dc678e0 [ 38.222579] x29:
ffffc0008dc678e0 x28: 0000000000042a97 x27:
ffff8000b701b480 [ 38.223465] x26:
00000000000000fb x25: ffffc0008dc67d20 x24:
ffffc0008dc67968 [ 38.224402] x23:
ffff8000e3ca5600 x22: ffff8000265b7800 x21:
ffff80003000c0c0 [ 38.225279] x20:
0000000000000000 x19: ffff8000b68c5200 x18:
ffffc0008dc67968 [ 38.226151] x17:
0000000000000000 x16: 0000000000000000 x15:
ffffc000810a30a8 [ 38.227042] x14:
00007fff637effff x13: 00005555de91ffff x12:
00007fff63293fff [ 38.227942] x11:
0000000000000000 x10: ffff8000184ecf08 x9 :
ffffc0007a1900c8 [ 38.228824] x8 :
ffffc0008dc67968 x7 : 0000000000000012 x6 :
ffffc0015cf1c000 [ 38.229703] x5 :
ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 :
0000000000000038 [ 38.230607] x2 :
0000000000000003 x1 : 0000000000000003 x0 :
00000000100000fb [ 38.231488] Call trace: [
38.231806] drm_gem_mmap_obj+0x1f8/0x210 (P) [
38.232342] drm_gem_mmap+0x140/0x260 [ 38.232813]
__mmap_region+0x488/0x9a0 [ 38.233277]
mmap_region+0xd0/0x148 [ 38.233703]
do_mmap+0x350/0x5c0 [ 38.234148]
vm_mmap_pgoff+0x14c/0x200 [ 38.234612]
ksys_mmap_pgoff+0x150/0x208 [ 38.235107]
__arm64_sys_mmap+0x34/0x50 [ 38.235611]
invoke_syscall+0x50/0x120 [ 38.236075]
el0_svc_common.constprop.0+0x48/0xf0 [ 38.236680]
do_el0_svc+0x24/0x38 [ 38.237113]
el0_svc+0x38/0x168 [ 38.237507]
el0t_64_sync_handler+0xa0/0xe8 [ 38.238034]
el0t_64_sync+0x198/0x1a0 [ 38.238491] ---[ end
trace 0000000000000000 ]--- There were discussions
in [1] at the end of 2023 that mmap() on imported
---truncated--- |
| CVE-2026-46314 |
In the Linux kernel, the
following vulnerability has been resolved:
drm/v3d: Reject empty multisync extension to
prevent infinite loop v3d_get_extensions() walks a
userspace-provided singly-linked list of ioctl
extensions without any bound on the chain length.
A local user can craft a self-referential
extension (ext->next == &ext) with zero
in_sync_count and out_sync_count, which bypasses
the existing duplicate- extension guard: if
(se->in_sync_count || se->out_sync_count)
return -EINVAL; The guard never fires because
v3d_get_multisync_post_deps() returns immediately
when count is zero, leaving both fields at zero on
every iteration. The result is an infinite loop in
kernel context, blocking the calling thread and
pegging a CPU core indefinitely. Fix this by
rejecting a multisync extension where both
in_sync_count and out_sync_count are zero in
v3d_get_multisync_submit_deps(). An empty
multisync carries no synchronization information
and serves no useful purpose, so returning -EINVAL
for such an extension is the correct defense
against this attack vector. |
| CVE-2026-46315 |
In the Linux kernel, the
following vulnerability has been resolved:
io_uring/waitid: clear waitid info before copying
it to userspace IORING_OP_WAITID stores its result
fields in struct io_waitid::info and later copies
them to userspace siginfo. The prep path
initializes the request arguments, but it does not
initialize info itself. If the wait operation
completes without reporting a child event, the
common wait code can return without writing
wo_info. In that case io_waitid_finish() still
copies iw->info to userspace, exposing stale
bytes from the reused io_kiocb command storage.
Clear the result storage during prep so the
io_uring path matches the regular waitid syscall,
which uses a zero-initialized struct
waitid_info. |
| CVE-2026-46319 |
In the Linux kernel, the
following vulnerability has been resolved:
net/sched: act_ct: Only release RCU read lock
after ct_ft When looking up a flow table in act_ct
in tcf_ct_flow_table_get(),
rhashtable_lookup_fast() internally opens and
closes an RCU read critical section before
returning ct_ft. The
tcf_ct_flow_table_cleanup_work() can complete
before refcount_inc_not_zero() is invoked on the
returned ct_ft resulting in a UAF on the already
freed ct_ft object. This vulnerability can lead to
privilege escalation. Analysis from
zdi-disclosures@trendmicro.com: When initializing
act_ct, tcf_ct_init() is called, which internally
triggers tcf_ct_flow_table_get(). static int
tcf_ct_flow_table_get(struct net *net, struct
tcf_ct_params *params) { struct zones_ht_key key =
{ .net = net, .zone = params->zone }; struct
tcf_ct_flow_table *ct_ft; int err = -ENOMEM;
mutex_lock(&zones_mutex); ct_ft =
rhashtable_lookup_fast(&zones_ht, &key,
zones_params); // [1] if (ct_ft &&
refcount_inc_not_zero(&ct_ft->ref)) // [2]
goto out_unlock; ... } static __always_inline void
*rhashtable_lookup_fast( struct rhashtable *ht,
const void *key, const struct rhashtable_params
params) { void *obj; rcu_read_lock(); obj =
rhashtable_lookup(ht, key, params);
rcu_read_unlock(); return obj; } At [1],
rhashtable_lookup_fast() looks up and returns the
corresponding ct_ft from zones_ht . The lookup is
performed within an RCU read critical section
through rcu_read_lock() / rcu_read_unlock(), which
prevents the object from being freed. However, at
the point of function return, rcu_read_unlock()
has already been called, and there is nothing
preventing ct_ft from being freed before reaching
refcount_inc_not_zero(&ct_ft->ref) at [2].
This interval becomes the race window, during
which ct_ft can be freed. Free Process:
tcf_ct_flow_table_put() is executed through the
path tcf_ct_cleanup() call_rcu()
tcf_ct_params_free_rcu() tcf_ct_params_free()
tcf_ct_flow_table_put(). static void
tcf_ct_flow_table_put(struct tcf_ct_flow_table
*ct_ft) { if
(refcount_dec_and_test(&ct_ft->ref)) {
rhashtable_remove_fast(&zones_ht,
&ct_ft->node, zones_params);
INIT_RCU_WORK(&ct_ft->rwork,
tcf_ct_flow_table_cleanup_work); // [3]
queue_rcu_work(act_ct_wq, &ct_ft->rwork); }
} At [3], tcf_ct_flow_table_cleanup_work() is
scheduled as RCU work static void
tcf_ct_flow_table_cleanup_work(struct work_struct
*work) { struct tcf_ct_flow_table *ct_ft; struct
flow_block *block; ct_ft =
container_of(to_rcu_work(work), struct
tcf_ct_flow_table, rwork);
nf_flow_table_free(&ct_ft->nf_ft); block =
&ct_ft->nf_ft.flow_block;
down_write(&ct_ft->nf_ft.flow_block_lock);
WARN_ON(!list_empty(&block->cb_list));
up_write(&ct_ft->nf_ft.flow_block_lock);
kfree(ct_ft); // [4] module_put(THIS_MODULE); }
tcf_ct_flow_table_cleanup_work() frees ct_ft at
[4]. When this function executes between [1] and
[2], UAF occurs. This race condition has a very
short race window, making it generally difficult
to trigger. Therefore, to trigger the
vulnerability an msleep(100) was inserted
after[1] |
| CVE-2026-46320 |
In the Linux kernel, the
following vulnerability has been resolved: tap:
free page on error paths in tap_get_user_xdp()
tap_get_user_xdp() rejects a frame shorter than
ETH_HLEN with -EINVAL, and returns -ENOMEM when
build_skb() fails. Both paths jump to the err
label without freeing the page that
vhost_net_build_xdp() allocated for the frame.
tap_sendmsg() discards the per-buffer return value
and always returns 0, so vhost_tx_batch() takes
the success path and never frees the page; each
rejected frame in a batch leaks one page-frag
chunk. Free the page on both error paths, before
the skb is built. This is the tap counterpart of
the same leak in tun_xdp_one(). |
| CVE-2026-46321 |
In the Linux kernel, the
following vulnerability has been resolved: tun:
free page on short-frame rejection in
tun_xdp_one() tun_xdp_one() returns -EINVAL on a
frame shorter than ETH_HLEN without freeing the
page that vhost_net_build_xdp() allocated for it.
tun_sendmsg() discards that -EINVAL and still
returns total_len, so vhost_tx_batch() takes the
success path and never frees the page; each short
frame in a batch leaks one page-frag chunk. A
local process that can open /dev/net/tun and
/dev/vhost-net can hit this path: it attaches a
tun/tap device as the vhost-net backend and feeds
TX descriptors whose length minus the virtio-net
header is below ETH_HLEN. Each kick leaks the
page-frag chunks for that batch, and a tight
submission loop exhausts host memory and triggers
an OOM panic. Free the page before returning
-EINVAL, matching the XDP-program error path in
the same function. |
| CVE-2026-46322 |
In the Linux kernel, the
following vulnerability has been resolved: tun:
free page on build_skb failure in tun_xdp_one()
When build_skb() fails in tun_xdp_one(), the
function sets ret to -ENOMEM and jumps to the out
label, which returns without freeing the page that
vhost_net_build_xdp() allocated for the frame. As
with the short-frame rejection path, tun_sendmsg()
discards the per-buffer error and still returns
total_len, so vhost_tx_batch() takes the success
path and never frees the page. Each build_skb()
failure in a batch leaks one page-frag chunk. Free
the page before taking the error path, matching
the put_page() the other error exits of
tun_xdp_one() already perform. |
| CVE-2026-46324 |
In the Linux kernel, the
following vulnerability has been resolved:
netfilter: nf_tables: use list_del_rcu for netlink
hooks nft_netdev_unregister_hooks and
__nft_unregister_flowtable_net_hooks need to use
list_del_rcu(), this list can be walked by
concurrent dumpers. Add a new helper and use it
consistently. |
| CVE-2026-46325 |
In the Linux kernel, the
following vulnerability has been resolved:
RDMA/rxe: Fix iova-to-va conversion for MR page
sizes != PAGE_SIZE The current implementation
incorrectly handles memory regions (MRs) with page
sizes different from the system PAGE_SIZE. The
core issue is that rxe_set_page() is called with
mr->page_size step increments, but the
page_list stores individual struct page pointers,
each representing PAGE_SIZE of memory.
ib_sg_to_page() has ensured that when i>=1
either a) SG[i-1].dma_end and SG[i].dma_addr are
contiguous or b) SG[i-1].dma_end and
SG[i].dma_addr are mr->page_size aligned. This
leads to incorrect iova-to-va conversion in
scenarios: 1) page_size < PAGE_SIZE (e.g., MR:
4K, system: 64K): ibmr->iova = 0x181800 sg[0]:
dma_addr=0x181800, len=0x800 sg[1]:
dma_addr=0x173000, len=0x1000 Access iova =
0x181800 + 0x810 = 0x182010 Expected VA: 0x173010
(second SG, offset 0x10) Before fix: - index =
(0x182010 >> 12) - (0x181800 >> 12) =
1 - page_offset = 0x182010 & 0xFFF = 0x10 -
xarray[1] stores system page base 0x170000 -
Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong)
2) page_size > PAGE_SIZE (e.g., MR: 64K,
system: 4K): ibmr->iova = 0x18f800 sg[0]:
dma_addr=0x18f800, len=0x800 sg[1]:
dma_addr=0x170000, len=0x1000 Access iova =
0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010
(second SG, offset 0x10) Before fix: - index =
(0x190010 >> 16) - (0x18f800 >> 16) =
1 - page_offset = 0x190010 & 0xFFFF = 0x10 -
xarray[1] stores system page for dma_addr 0x170000
- Resulting VA: system page of 0x170000 + 0x10 =
0x170010 (wrong) Yi Zhang reported a kernel
panic[1] years ago related to this defect.
Solution: 1. Replace xarray with pre-allocated
rxe_mr_page array for sequential indexing (all MR
page indices are contiguous) 2. Each rxe_mr_page
stores both struct page* and offset within the
system page 3. Handle MR page_size != PAGE_SIZE
relationships: - page_size > PAGE_SIZE: Split
MR pages into multiple system pages - page_size
<= PAGE_SIZE: Store offset within system page
4. Add boundary checks and compatibility
validation This ensures correct iova-to-va
conversion regardless of MR page size and system
PAGE_SIZE relationship, while improving
performance through array-based sequential access.
Tests on 4K and 64K PAGE_SIZE hosts: -
rdma-core/pytests $ ./build/bin/run_tests.py --dev
eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1
USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd
[1]
https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/ |
| CVE-2026-46330 |
In the Linux kernel, the
following vulnerability has been resolved: Revert
"net/smc: Introduce TCP ULP support" This reverts
commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.
As reported by Al Viro, the TCP ULP support for
SMC is fundamentally broken. The implementation
attempts to convert an active TCP socket into an
SMC socket by modifying the underlying `struct
file`, dentry, and inode in-place, which violates
core VFS invariants that assume these structures
are immutable for an open file, creating a risk of
use after free errors and general system
instability. Given the severity of this design
flaw and the fact that cleaner alternatives (e.g.,
LD_PRELOAD, BPF) exist for legacy application
transparency, the correct course of action is to
remove this feature entirely. |
| CVE-2026-46333 |
In the Linux kernel, the
following vulnerability has been resolved: ptrace:
slightly saner 'get_dumpable()' logic The
'dumpability' of a task is fundamentally about the
memory image of the task - the concept comes from
whether it can core dump or not - and makes no
sense when you don't have an associated mm. And
almost all users do in fact use it only for the
case where the task has a mm pointer. But we have
one odd special case: ptrace_may_access() uses
'dumpable' to check various other things entirely
independently of the MM (typically explicitly
using flags like PTRACE_MODE_READ_FSCREDS).
Including for threads that no longer have a VM
(and maybe never did, like most kernel threads).
It's not what this flag was designed for, but it
is what it is. The ptrace code does check that the
uid/gid matches, so you do have to be uid-0 to see
kernel thread details, but this means that the
traditional "drop capabilities" model doesn't make
any difference for this all. Make it all make a
*bit* more sense by saying that if you don't have
a MM pointer, we'll use a cached "last
dumpability" flag if the thread ever had a MM (it
will be zero for kernel threads since it is never
set), and require a proper CAP_SYS_PTRACE
capability to override. |
| CVE-2026-46338 |
# Summary `pymdownx.snippets`
has a regression of the CVE-2023-32309 /
GHSA-jh85-wwv9-24hv fix. With `restrict_base_path:
True` (the default), the current
`filename.startswith(base)` containment check does
not enforce a directory boundary. As a result, a
markdown snippet directive can read files from
sibling paths that share the same prefix as
`base_path`, such as `docs` vs `docs_internal`.
The regression was introduced in PR #2039 / commit
`7c13bda5b7793b172efd1abb6712e156a83fe07d`, which
replaced the original directory-identity check
with a plain string-prefix comparison. # Details
The regression was introduced in commit
`7c13bda5b7793b172efd1abb6712e156a83fe07d`
(2023-05-15, #2039 *"Fix regression of snippets
nested deeply under specified base path"*), which
relaxed the original `os.path.samefile(base,
os.path.dirname(filename))` check to a plain
`startswith(base)`.
`SnippetPreprocessor.get_snippet_path()` in
`pymdownx/snippets.py`: ```python if
self.restrict_base_path: filename =
os.path.abspath(os.path.join(base, path)) # If the
absolute path is no longer under the specified
base path, reject the file if not
filename.startswith(base): continue ``` `base` is
`os.path.abspath(b)` and has no trailing
separator. `str.startswith(base)` is `True` for
any `filename` whose string representation begins
with the same characters as `base`, regardless of
whether those characters end at a directory
boundary. Concrete example: * `base = "/x/docs"` *
`path = "../docs_secret/leak.txt"` (inside the
markdown snippet directive) * `os.path.join(base,
path)` → `"/x/docs/../docs_secret/leak.txt"` *
`os.path.abspath(...)` →
`"/x/docs_secret/leak.txt"` *
`filename.startswith(base)` → `True`, because
`"/x/docs_secret/..."` begins with the literal
string `"/x/docs"`. All releases from **10.0.1
(2023-05-15) through 10.21.2 (current)** are
affected. # Impact Arbitrary file read within the
host the build runs on, bounded by the prefix
match. With `base_path = /x/docs` the attacker can
read files from any sibling directory whose path
begins with the literal string `/x/docs` followed
by any non-separator character — for example
`/x/docs_internal/`, `/x/docs.bak/`, `/x/docs2/`.
The threat model is the same as the original
CVE-2023-32309: markdown content processed by the
snippets preprocessor in a build pipeline (typical
scenario: an MkDocs documentation site built in CI
from PR contributions or otherwise less-trusted
markdown) can read files outside the configured
base. CI builds that publish the generated HTML
expose the read file to the public; CI builds with
secrets on disk leak those secrets. # Reproduction
Minimal local PoC, non-destructive: ```python
import os, shutil, tempfile, markdown work =
tempfile.mkdtemp(prefix="pmx_poc_") try: base =
os.path.join(work, "docs") sibling =
os.path.join(work, "docs_secret")
os.makedirs(base) os.makedirs(sibling) with
open(os.path.join(sibling, "leak.txt"), "w") as f:
f.write("TOP_SECRET_FROM_SIBLING_DIR\n") out =
markdown.markdown( '--8<--
"../docs_secret/leak.txt"\n',
extensions=["pymdownx.snippets"],
extension_configs={ "pymdownx.snippets": {
"base_path": [base], "restrict_base_path": True,
"check_paths": True, } }, ) print(out) # ->
<p>TOP_SECRET_FROM_SIBLING_DIR</p>
finally: shutil.rmtree(work) ``` Default
`restrict_base_path: True` is sufficient — no
non-default option is required. # Suggested fix
Minimal change — require the separator after the
base prefix: ```diff - if not
filename.startswith(base): + # Append `os.sep` so
a sibling directory whose name shares a prefix + #
(e.g. `/x/docs` vs `/x/docs_evil`) cannot satisfy
the check. + if not filename.startswith(base +
os.sep): continue ``` This preserves the original
intent (allow snippets nested at any depth under
`base_path`) while restoring the
directory-boundary check. It does not affect the
`os.path.isdir(base)` branch where `base` is a
file (that branch still uses `os.path.samefile`).
Alternative: `os.path.commonpath([base, filename])
== base` is equivalent and slightly more
idiomatic, though it raises `ValueError` on
different drives on Windows and would need a
`try/except`. The `startswith(base + os.sep)` fix
is the smaller diff. Note: this fix does not
change behaviour for symlinks inside `base_path`.
The existing implementation uses `os.path.abspath`
(not `os.path.realpath`), so a symlink within
`base_path` pointing outside is still followed.
That is a separate concern — symlinks require
write access to `base_path`, a much higher bar
than the current bypass — and matches the
behaviour the CVE-2023 fix established. #
Regression test A regression test class
`TestSnippetsSiblingPrefix` was added in
`tests/test_extensions/test_snippets.py`. It uses
`tests/test_extensions/_snippets/nested` as
`base_path` and a new fixture directory
`tests/test_extensions/_snippets/nested_sibling_evil/leak.txt`.
It asserts that the markdown directive `--8<--
"../nested_sibling_evil/leak.txt"` raises
`SnippetMissingError`. * Without fix: test fails
(`AssertionError: SnippetMissingError not raised`,
sibling file is silently read). * With fix: test
passes. Full suite: `python -m pytest tests/ -q` →
**738 passed** (737 baseline + 1 new regression
test). No regressions. # Affected versions `>=
10.0.1, <= 10.21.2` |
| CVE-2026-47214 |
### Impact The HTML backend
did not perform sufficient validation during
resource handling: - Accepted `file://` URIs
enabling local file system access when
`enable_local_fetch=True` - Path resolution
allowed traversal outside intended directories via
`../` sequences and absolute paths - Did not block
internal network resources under
`enable_remote_fetch=True` - HTTP redirects were
not validated, potentially redirecting to
unintended schemes - No resource limits for remote
image downloads and `data:` URIs ### Patches Fixed
in versions 2.91.0 (initial fixes) and 2.94.0
(additional improvements). The fixes implement: -
Updated local path treatment: absolute files
always blocked, relative paths require
`enable_local_fetch=True` (default: False) and
containment within configured `base_path` for path
traversal protection - `file://` scheme stripped
& treated as local path (above) - IP address
validation to prevent SSRF - HTTP redirect
validation, connection and read timeouts - Size
limit for both remote images (with streaming
download) and base64-decoded data URIs ###
Workarounds Keep both `enable_local_fetch=False`
and `enable_remote_fetch=False` (defaults) when
processing untrusted HTML documents. ###
References - Initial fixes:
[v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0)
- Additional improvements:
[v2.94.0](https://github.com/docling-project/docling/releases/tag/v2.94.0) |
| CVE-2026-47326 |
Ubuntu Linux 6.8, 6.17 and 7.0
contain SAUCE patches with a memory leak in the
handling of big responses to AppArmor
notifications. The bug can be triggered by an
unprivileged local user. The memory leak could
lead to resource exhaustion. |
| CVE-2026-47327 |
Ubuntu Linux 6.8, 6.17 and 7.0
contain SAUCE patches with a possible NULL pointer
dereference in the handling of AppArmor
notifications. The bug can be triggered by an
unprivileged local user. This can lead to a kernel
oops. |
| CVE-2026-47328 |
Ubuntu Linux 6.8, 6.17 and 7.0
contain AppArmor SAUCE patches which incorrectly
attempt to free a pointer which was not previously
kmalloc()d, while at the same time leaking
allocated memory. The bug can be triggered by an
unprivileged local user and can result in the
corruption of slab metadata and could lead to
resource exhaustion. |
| CVE-2026-47329 |
Ubuntu Linux 6.8, 6.17 and 7.0
contain SAUCE patches which fail to validate
invalid sizes of the name field in AppAmor
notification responses. The bug can be triggered
by an unprivileged local user and could result in
handling of crafted responses. |
| CVE-2026-47330 |
Ubuntu Linux 6.8, 7.17 and 7.0
contain AppArmor SAUCE patches which can, under
certain circumstances, use an uninitialized
variable in notification handling code. The bug
can be triggered by an unprivileged local user and
can result in the incorrect caching of AppArmor
notification responses. |
| CVE-2026-47331 |
Ubuntu Linux 6.8 contains
AppArmor SAUCE patches which fail to acquire a
lock when modifying a linked list. An unprivileged
local user could trigger the race condition that
can lead to a use-after-free (UAF) and,
theoretically, arbitrary code execution. |
| CVE-2026-47332 |
Ubuntu Linux 6.8, 6.17 and 7.0
contain AppArmor SAUCE patches which incorrectly
validate the size of an internal structure,
leading to an out-of-bounds read in notification
handling code. The bug can be triggered by an
unprivileged local user and can result in
information disclosure from adjacent slab
objects. |
| CVE-2026-47333 |
Ubuntu Linux 6.8, 6.17 and 7.0
contain AppArmor SAUCE patches which can
potentially incorrectly compute the size of an
internal buffer, leading to a heap memory
out-of-bounds read in notification handling code.
The bug can be triggered by an unprivileged local
user and can result in invalid data being
processed by the AppArmor DFA policy
engine. |
| CVE-2026-47334 |
Ubuntu Linux 6.8, 6.17 and 7.0
contain AppArmor SAUCE patches which incorrectly
sleep while holding a spinlock in notification
handling code. The bug can be triggered by an
unprivileged local user and can result in kernel
panic or deadlock. |
| CVE-2026-47335 |
Ubuntu Linux 6.8 contains
SAUCE patches with a possible NULL pointer
dereference in the handling of AppArmor
notifications. The bug can be triggered by an
unprivileged local user. This can lead to a kernel
panic. |
| CVE-2026-47336 |
Ubuntu Linux 6.8 contains
SAUCE patches with a possible use of an
uninitialized variable in AppArmor
AF_INET/AF_INET6 socket mediation code. The bug
can be triggered by an unprivileged local user and
could result in incorrect fine-grained mediation
of network sockets. |
| CVE-2026-47337 |
Ubuntu Linux 6.8, 6.17 and 7.0
contain SAUCE patches with a possible NULL pointer
dereference in the handling of AF_INET/AF_INET6
socket mediation. The bug can be triggered by an
unprivileged local user. This can lead to a kernel
oops. |
| GHSA-rf74-v2fm-23pw |
### Summary
`JSONTaggedDecoder.decode_obj()` in
`nltk/jsontags.py` calls itself recursively
without any depth limit. A deeply nested JSON
structure exceeding `sys.getrecursionlimit()`
(default: 1000) will raise an unhandled
`RecursionError`, crashing the Python
process. |
| GHSA-wwhq-w58m-w29c |
# ## TL;DR CVE-2026-30852
fixed double expansion in `vars_regexp` when the
variable key is a placeholder (e.g.
`{http.vars.x}`). The fix does NOT protect literal
key names (e.g. `tenant_id`). An attacker injects
`{env.AWS_SECRET_ACCESS_KEY}` or
`{file./etc/passwd}` via a request header → Caddy
expands it on the second pass → secrets leaked in
response headers. |
