🚨 CVE-2026-98125
In the Linux kernel, the following vulnerability has been resolved:

smb/client: fix stale page cache in insert/collapse range

smb3_insert_range() and smb3_collapse_range() use
truncate_pagecache_range() to invalidate the affected page cache.
However, if off or old_eof is not page-aligned, the boundary pages are
only partially zeroed and remain uptodate. As a result, the client may
return stale data after a successful insert/collapse range operation.

For example, with 4K pages:

page 0 page 1 page 2
0------4K 4K------8K 8K------12K
^ ^
off=2K old_eof=10K

Page 1 is removed from the page cache, while the boundary pages are
only partially zeroed. After COPYCHUNK moves the data on the server,
these cached pages may still return stale data.

This can be reproduced on a CIFS mount:

bash -c '
FILE=/mnt/scratch/repro

# Use a 6 KiB file so EOF is not page-aligned.
dd if=/dev/urandom of=/tmp/src bs=1K count=6 status=none

# Expected: a 4 KiB hole followed by the original data.
rm -f /tmp/expected
truncate -s 4K /tmp/expected
cat /tmp/src >> /tmp/expected

cp /tmp/src "$FILE"

# Prime the page cache before moving data on the server.
cat "$FILE" > /dev/null

fallocate --insert-range -o 0 -l 4K "$FILE"

if cmp -s /tmp/expected "$FILE"; then
echo "readback: OK"
else
echo "readback: STALE DATA"
fi
'

Fix this by writing back dirty data and discarding the page cache from
the start of the page containing off to EOF before moving data on the
server.

🎖@cveNotify

🚨 CVE-2026-98126
In the Linux kernel, the following vulnerability has been resolved:

smb/client: validate new EOF for zero range

When FALLOC_FL_ZERO_RANGE is used without FALLOC_FL_KEEP_SIZE,
smb3_zero_range() may extend EOF without checking RLIMIT_FSIZE, allowing
the file to grow beyond the caller's file-size limit.

Fix this by calling inode_newsize_ok() before sending the zero-range
request when the operation would extend EOF.

Reproducer, using a file on a CIFS mount:

bash -c '
FILE=/mnt/cifs/repro

trap "" SIGXFSZ
ulimit -f 3072

truncate -s 2M "$FILE"
fallocate --zero-range -o 0 -l 4M "$FILE"
echo "fallocate rc=$?"
stat -c "file size=%s" "$FILE"
'

Before this change, the operation succeeds despite the 3 MiB limit:

fallocate rc=0
file size=4194304

After this change, fallocate fails and leaves the file at 2 MiB.

🎖@cveNotify

🚨 CVE-2026-98127
In the Linux kernel, the following vulnerability has been resolved:

smb/client: validate new EOF for insert range

smb3_insert_range() does not check if the new file size
(i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass
RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t
range.

Use check_add_overflow() to calculate the new EOF. Validate it with
inode_newsize_ok() before modifying the file.

Reproducer, using a file on a CIFS mount:

bash -c '
FILE=/mnt/cifs/repro

trap "" SIGXFSZ
ulimit -f 3072 # RLIMIT_FSIZE = 3 MiB

# A regular write is stopped at 3 MiB.
dd if=/dev/zero of="$FILE" bs=1M count=4 status=none
stat -c "size after write: %s" "$FILE"

# Insert 2 MiB into a 2 MiB file.
truncate -s 2M "$FILE"
fallocate -i -o 0 -l 2M "$FILE"
stat -c "size after insert: %s" "$FILE"
'

Before this change, the regular write stops at the 3 MiB limit, but
insert range grows the file to 4 MiB:

dd: error writing '/mnt/cifs/repro': File too large
size after write: 3145728
size after insert: 4194304

After this change, insert range also fails at the limit and leaves the
2 MiB file unchanged:

dd: error writing '/mnt/cifs/repro': File too large
size after write: 3145728
fallocate: fallocate failed: File too large
size after insert: 2097152

🎖@cveNotify

🚨 CVE-2026-98128
In the Linux kernel, the following vulnerability has been resolved:

scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add()

mpi3mr_get_tgtdev_by_addr() increments the target device kref when it
returns a device. If a subsequent error triggers a goto out_fail after
the tgtdev reference is acquired, the reference is never released
because the out_fail path does not call mpi3mr_tgtdev_put(). This
prevents the target device structure from ever being freed.

Add a tgtdev put in the out_fail path, guarded by a NULL check since
tgtdev is only acquired for SAS_END_DEVICE types and the same cleanup
path is shared by earlier error cases where tgtdev is still NULL.

🎖@cveNotify

🚨 CVE-2026-98129
In the Linux kernel, the following vulnerability has been resolved:

scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add()

sas_port_alloc_num() can return NULL on memory allocation failure. The
return value is passed directly to sas_port_add() without a NULL check,
which causes a NULL pointer dereference.

Additionally, if sas_port_add() fails, the allocated port is not freed
before jumping to out_fail, leaking the sas_port structure. Call
sas_port_free() to properly release it.

🎖@cveNotify

🚨 CVE-2026-98130
In the Linux kernel, the following vulnerability has been resolved:

sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START

The SCTP_CMD_TIMER_START handler checks timer_pending() before calling
timer_reduce(). The timer can expire and detach between these operations,
causing timer_reduce() to rearm the timer without taking the association
reference required for the newly armed timer.

The timer callback later unconditionally drops its association reference,
which can leave the association reference count unbalanced and result in
use-after-free during association teardown.

Use the return value of timer_reduce() to determine whether the timer was
actually armed. Take the association reference only when timer_reduce()
successfully starts a new timer, closing the race between checking the
timer state and rearming it.

This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero
Day Initiative.

🎖@cveNotify

🚨 CVE-2026-98131
In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: fix dma mapping leak in stmmac_tso_xmit()

In stmmac_tso_xmit(), if the DMA mapping of an skb fragment fails, the
frame is dropped but the DMA mappings already created for the linear
part and for the fragments mapped before the failure are never
unmapped, leaking DMA mappings.

Fix the leak by walking back over the descriptors used by the frame and
releasing each of them with stmmac_free_tx_buffer(). Moreover, release
the descriptors with stmmac_release_tx_desc() unmapping the DMA buffers.

🎖@cveNotify

🚨 CVE-2026-98132
In the Linux kernel, the following vulnerability has been resolved:

bpf: don't downgrade half-dead scalar zero spills to STACK_ZERO

states.c:__clean_func_state() can downgrade scalar zero spill to
STACK_ZERO in the following case:

*(u64 *)(r10 - 8) = 0;
... checkpoint ...
r1 = *(u32 *)(r10 - 4);
... no reads from r10-8 ...

Here 4 bytes at r10-8 are dead and verifier changes scalar spill to a
combination: 0000pppp (p stands for poison). Such a change breaks
precision propagation chains. All places that produce STACK_ZERO
should call bpf_mark_chain_precision() for the zero source.

This patch fixes the bug in a simplest way possible:
avoids converting stack spills of zero to STACK_ZERO.
Two smarter approaches are possible:
- do bpf_mark_chain_precision() from __clean_func_state()
- check slot liveness information in check_stack_write_fixed_off()

I investigated both and the changes required are a bit tricky,
hence go with a simple fix for the time being.

🎖@cveNotify

🚨 CVE-2026-98133
In the Linux kernel, the following vulnerability has been resolved:

ntfs: leave HasEA flag untouched on setxattr failure

In ntfs_set_ea(), the exit path unconditionally updates the HasEA
flag based on ea_info_qsize. When an error occurs before
ea_info_qsize is updated, NInoClearHasEA() hides existing on-disk
EAs until the inode is evicted.

Only update the flag on success.

🎖@cveNotify

🚨 CVE-2026-98134
In the Linux kernel, the following vulnerability has been resolved:

bpf: check_cond_jmp_op(): properly infer if register is null

Nicholas Carlini reported a bug when verifier can incorrectly infer
that a pointer is non-null. The bug occurs when two pointers are
compared and one of them has a type w/o PTR_MAYBE_NULL flag,
but which allows a value to be NULL at runtime.
Here is an example:

// `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED
// `a` is 0 at runtime.
// `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL
void *a = bpf_rdonly_cast(0, 0);
int *b = bpf_map_lookup_elem(...);

if (a == b)
*b = 42; // verifier does not catch null pointer dereference

This happens because of a special case in check_cond_jmp_op(),
which attempts to strip PTR_MAYBE_NULL flags from pointer types,
when processing comparisons like `rA == rB`, if either rA or rB can't
be null.

The non-null property is derived based on the absence of
PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient
for types like PTR_TO_MEM, as in the example.

This patch replaces type_may_be_null() call with reg_not_null(),
which contains an allowlist of types for which absence of
PTR_MAYBE_NULL actually means that the value can't be NULL at runtime.

At the moment, the list in the reg_not_null() omits two types for
which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF.
In order to remain backward compatible, and assuming that only
comparison between pointers of the same type makes sense,
this commit extends reg_not_null(). W/o such an extension e.g.
verifier_jeq_infer_not_null/null_ptr_to_map_value fails.

reg_not_null() can be extended further, but I deem that out of scope
for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID
checks in the check_cond_jmp_op() can be removed with migration to
reg_not_null(), but that is a behavioural change, as the special case
would start matching for PTR_TO_BTF_ID that is also is_trusted_reg().
I omit the behavioural change from this commit.

🎖@cveNotify

🚨 CVE-2026-98135
In the Linux kernel, the following vulnerability has been resolved:

ntfs: reject invalid sectors_per_cluster in the boot sector

is_boot_sector_ntfs() checks the boot sector's sectors_per_cluster field
with a range test that rejects 0x81..0xf3 but accepts 0 and other
non-power-of-two counts. A zero value reaches parse_ntfs_boot_sector():

sectors_per_cluster_bits = ffs(sectors_per_cluster) - 1;
...
vol->cluster_size = vol->sector_size << sectors_per_cluster_bits;

ffs(0) is 0, so sectors_per_cluster_bits becomes (unsigned)-1 and the
shift is undefined:

UBSAN: shift-out-of-bounds in fs/ntfs/super.c:673:39
shift exponent 4294967295 is too large for 32-bit type 'int'

This change rejects any non-power-of-two value, since it feeds the
aforementioned shift via ffs() - 1, which only yields the correct shift for a
power of two.

🎖@cveNotify

🚨 CVE-2026-98136
In the Linux kernel, the following vulnerability has been resolved:

ntfs: bound $AttrDef table walk to the loaded table size

ntfs_attr_find_in_attrdef() walks the in-memory $AttrDef table, but the
loop condition bounds only the start of each entry, not the whole entry:

for (ad = vol->attrdef; (u8 *)ad - (u8 *)vol->attrdef <
vol->attrdef_size && ad->type; ++ad)

struct attr_def is 160 bytes; the guard reads ad->type at offset 128 and
the loop body reads further fields. vol->attrdef is kvzalloc(i_size),
where i_size is the on-disk $AttrDef data size, checked in
load_and_init_attrdef() only as 0 < i_size <= 0x7fffffff. A volume whose
$AttrDef data size is smaller than one entry (e.g. 120 bytes) makes the
read of ad->type run past the allocation. Creating a file reaches this
through ntfs_attr_size_bounds_check() and reads out of bounds:

BUG: KASAN: slab-out-of-bounds in ntfs_attr_find_in_attrdef+0x66/0xa0
Read of size 4 at addr ffff888005833280 by task init/1
ntfs_attr_find_in_attrdef
ntfs_attr_size_bounds_check
ntfs_attr_can_be_non_resident
ntfs_attr_add

Require the whole entry to lie within attrdef_size in the loop guard, and
reject at mount a $AttrDef too small to hold one attr_def entry.

🎖@cveNotify

🚨 CVE-2026-98137
In the Linux kernel, the following vulnerability has been resolved:

ntfs: treat any nonzero dio zero-range return as an error

ntfs_dio_zero_range() returns either 0 or a negative errno from
blkdev_issue_zeroout(); it never returns a positive value. The
zeroing failure check in ntfs_attr_fallocate() therefore never fired,
so a failed zeroing operation was silently ignored: the loop kept
going, the newly allocated clusters were folded into initialized_size
and the write could succeed leaving stale on-disk data.

Treat any nonzero return as an error and abort the allocation.

🎖@cveNotify

🚨 CVE-2026-98138
In the Linux kernel, the following vulnerability has been resolved:

ntfs: do not mark the volume clean in sync_fs when errors were recorded

ntfs_put_super() and the remount-read-only path both clear the dirty bit
only when NVolErrors(vol) is false. ntfs_sync_fs() clears it
unconditionally, so any sync() on a volume that recorded an error marks
that volume clean. A volume without this set is then seen as not needing
recovery and it does not run one, so whatever went wrong is never repaired.

This change skips resetting the dirty bit when there are volume errors.

Reproduced on a volume whose $MFTMirr does not match $MFT, which sets the
error flag while leaving the mount read-write: after a write and a sync,
the on-disk volume flags read 0x0000 with this driver and 0x0001 with the
guard in place.

🎖@cveNotify

🚨 CVE-2026-98139
In the Linux kernel, the following vulnerability has been resolved:

ntfs: only count successfully cleared runs when freeing clusters

ntfs_cluster_free_from_rl_nolock() adds a run's length to nr_freed
whenever the error bookkeeping condition is false, which includes
cases where ntfs_bitmap_clear_run() actually failed - e.g. a second
run failing with the same errno as an earlier one, or any failure
after a non-ENOMEM error was already recorded. Since a failed
ntfs_bitmap_clear_run() rolls back its partial modifications, no
bits were cleared for that run, yet its length still inflates
vol->free_clusters, corrupting statfs output and the allocator's
free space gate.

Only count runs whose bitmap clear succeeded.

🎖@cveNotify

🚨 CVE-2026-98140
In the Linux kernel, the following vulnerability has been resolved:

ntfs: fix kmap_local leak in write_mft_record_nolock() error paths

write_mft_record_nolock() maps the MFT record folio with
kmap_local_folio(), but the pre_write_mst_fixup() and
bio_add_folio() failure paths jump to the error label without
unmapping it. kmap_local mappings are stack-ordered per task, so
leaking one corrupts the nesting for any outer mapping.

Unmap the folio on those error paths too.

🎖@cveNotify

🚨 CVE-2026-98141
In the Linux kernel, the following vulnerability has been resolved:

ntfs: propagate reparse index insertion failure

update_reparse_data() ignores the return value of
set_reparse_index(). When index insertion fails, the code removes
the just-written reparse data as cleanup but still returns 0, so
symlink(2) (and WSL special file creation) reports success while
no reparse data exists on disk. When there was no previous reparse
data (oldsize == 0), the failure was likewise silently ignored.

Propagate the error to the caller.

🎖@cveNotify

🚨 CVE-2026-98142
In the Linux kernel, the following vulnerability has been resolved:

drm/cirrus-qemu: Validate BAR0 size during probe

The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate
framebuffer sizes. However, during PCI probe, the driver mapped BAR0
without verifying that its size matches `CIRRUS_VRAM_SIZE`.

If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the
mapped VRAM will be smaller than expected. Because validation checks assume
4 MB VRAM, framebuffers larger than the mapped memory can be created.

When the display plane is updated (e.g. during release),
`cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to
VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory
causes a supervisor write page fault:

BUG: unable to handle page fault for address: ffffc9000389c000
...
RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110
...
Call Trace:
<TASK>
iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline]
drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442
cirrus_primary_plane_helper_atomic_update+0x98a/0xb00
drivers/gpu/drm/tiny/cirrus-qemu.c:358
drm_atomic_helper_commit_planes+0x626/0xea0
drivers/gpu/drm/drm_atomic_helper.c:3038
drm_atomic_helper_commit_tail+0x60/0x510
drivers/gpu/drm/drm_atomic_helper.c:1989
commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074
drm_atomic_helper_commit+0xa77/0xb10
drivers/gpu/drm/drm_atomic_helper.c:2312

Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource
is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less.

🎖@cveNotify

🚨 CVE-2026-98144
In the Linux kernel, the following vulnerability has been resolved:

accel/amdxdna: put the chained BO when its mapping fails

amdxdna_cmd_set_error() looks up the first BO of a command chain, which
takes a reference, and drops it at the end of the function. The mapping of
that BO is established in between, and the failure path returns without the
put, so the reference is leaked.

Ordinary use does not reach it. The chain has been submitted before any of
this runs, so aie2_cmdlist_fill_slot() has already called
amdxdna_cmd_get_op() on that BO and amdxdna_gem_vmap() has cached its
address. What makes it reachable is that the BO is resolved again by
handle here, and the handle is userspace's to recycle: closing it after
submission and importing a dma-buf whose exporter implements no vmap onto
the same id leaves amdxdna_gem_get_obj() returning an object this cannot
map, since prime_import() types every import AMDXDNA_BO_SHARE.

🎖@cveNotify

🚨 CVE-2026-98145
In the Linux kernel, the following vulnerability has been resolved:

accel/amdxdna: reject a command chain that carries no commands

A chain whose command_count is zero passes the payload length check,
because struct_size(payload, data, 0) is just the header. The fill loop
then does not run, so offset stays zero and the request is submitted with
a zero-length buffer.

On firmware without AIE2_NPU_COMMAND that ends at the opcode check, since
op is still ERT_INVALID_CMD and aie2_get_chain_msg_op() answers
MSG_OP_MAX_OPCODE. aie2_get_npu_chain_msg_op() answers
MSG_OP_CHAIN_EXEC_NPU whatever it is given, so there the submission
continues to drm_clflush_virt_range(cmd_buf, 0), which reads the byte
before the buffer and faults on the vmap guard page. EXEC_CMD is
reachable by any process that can open the render node.

Reject the request instead.

🎖@cveNotify

🚨 CVE-2026-98146
In the Linux kernel, the following vulnerability has been resolved:

accel/amdxdna: Remove __counted_by from struct amdxdna_cmd_chain

struct amdxdna_cmd_chain contains a flexible array annotated with
__counted_by(command_count). Since the structure is stored in shared
AMDXDNA_BO_SHARE memory, userspace can modify command_count concurrently.
If command_count is changed to zero, the bounds check generated from
__counted_by may fail and trigger a kernel panic.

Remove __counted_by to avoid relying on the userspace-controlled
command_count for the flexible array bounds check.

🎖@cveNotify