| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
smb/client: flush dirty data before punching a hole
Punching a hole after a large buffered write may leave the range
reported as data. Reproduce it with:
xfs_io -f \
-c "pwrite -b 3m -S 0x61 0 3m" \
-c "fpunch 1m 1m" \
-c "seek -h 0" \
-c "seek -d 1m" \
/mnt/test/repro
Punching 1 MiB at offset 1 MiB should produce:
0 1 MiB 2 MiB 3 MiB
| DATA | HOLE | DATA | EOF
Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF,
and SEEK_DATA(1M) returns 1M.
This happens because a dirty folio spanning the punched range can be
written back after the punch and refill the hole.
Fix this by flushing and waiting for dirty data in the punched range
before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA.
The xfstests generic/539 pass against Samba/ksmbd with this change. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: validate TX_CMD response layout
TX_CMD parsing uses frame_count to walk status entries and then
read the trailing SCD SSN. Make the minimum-length check follow
that exact runtime layout calculation before parsing the payload.
For new TX API, reject TX_CMD responses with frame_count != 1 and
warn/return in the aggregation handler to document that aggregated
accounting is expected via BA notifications. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix a possible underflow
We shouldn't trust the firmware about the length of the wowlan packet. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: add a check on the tid coming from the firmware
ba_notif->tid is a firmware-controlled u8 that is used directly
as an array index into tid_data[] without any validation. Add a
bounds check against IWL_MAX_TID_COUNT before dereferencing the
array. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix out-of-bounds tid_data access in BA notif
mvmsta->tid_data was indexed by the TFD loop counter 'i' instead of
the actual TID value 'tid'. This writes lq_color into a random tid_data
slot unrelated to the BA entry.
Since multi-TID blockack is not really in use, 'i' was always 0 and no
harm was done.
Add a out-of-bound check before accessing the array. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: bound aligned TLV advance in FW parser
Validate ALIGN(tlv_len, 4) against remaining parser length before
consuming bytes from the firmware image.
This avoids length underflow on malformed TLVs. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: acpi: validate WGDS table revision index
Check tbl_rev bounds before BIT(tbl_rev) to avoid undefined shifts when
firmware reports an invalid revision value. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: bound dirent name against end of SMB response in cifs_filldir
cifs_filldir() copies the entry name out of an SMB1 TRANS2_FIND_FIRST /
FIND_NEXT response using a length (de.namelen) supplied by the server.
The kmalloc'd SMB response buffer is bounded, but nothing checks that
de.name + de.namelen still lies inside that buffer before the eventual
filldir64() -> verify_dirent_name() -> memchr() reads namelen bytes.
A hostile SMB1 server that returns an oversized FileNameLength in a
directory entry therefore causes memchr() to read past the end of the
response slab buffer. Reachable from any user who can list a directory
on a CIFS mount served by an attacker-controlled server (getdents64()
on the mounted directory):
BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80
Read of size 1 at addr ffff88800e0640cc by task poc/115
Call Trace:
dump_stack_lvl+0x64/0x80
print_report+0xce/0x620
kasan_report+0xec/0x120
memchr+0x71/0x80
filldir64+0x4c/0x6a0
cifs_filldir.constprop.0+0x9bb/0x1e00
cifs_readdir+0x2101/0x3380
iterate_dir+0x19c/0x520
__x64_sys_getdents64+0x126/0x210
do_syscall_64+0x107/0x5a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Pass the end-of-response pointer down to cifs_filldir() and reject
entries whose name would extend past that boundary.
This bug was discovered by Artiphishell's vTriage pipeline, which
generated a userspace reproducer (an emulated hostile SMB1 server plus
a getdents64() client) that reliably triggers the KASAN report on an
unpatched kernel. The fix below was drafted with the Claude coding
assistant; a userspace reproducer is available on request. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: preserve VFS inherited POSIX ACL mask
The VFS initializes a child's POSIX ACL from the parent's default ACL and
the requested creation mode. Do not mutate the parent ACL or overwrite the
child's VFS-computed access and default ACLs afterwards.
This preserves restrictive ACL_MASK entries and prevents SMB object creation
from widening effective permissions. |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: validate idmap key payload length
The cifs.idmap key type stores its payload length in key->datalen, which
is limited to U16_MAX. Accepting a larger key payload truncates the
recorded length and can make later users interpret the payload using
inconsistent bounds.
Reject oversized preparsed payloads before allocating or copying them.
This keeps key->datalen consistent with the stored data for both inline
and separately allocated idmap payloads. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()
The KASAN allocation trace shows that a malformed IE buffer is
stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any
validation. The crash trace shows that a subsequent SIOCSIWESSID
triggers a connection attempt which calls cfg80211_sme_get_conn_ies()
to process the stored IE buffer, causing:
- An out-of-bounds read in skip_ie() which reads ies[pos+1]
(the length byte) past the end of the 1-byte buffer.
- An integer underflow in the memcpy size argument when offs
returned by ieee80211_ie_split() exceeds ies_len, causing
unsigned subtraction to wrap to SIZE_MAX and triggering a
fortify panic.
Fix this by validating the IE buffer in cfg80211_wext_siwgenie()
before storing it.
[drop unnecessary ie_len check, update commit message] |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: validate skb length in rfcomm_recv_frame
rfcomm_recv_frame() casts skb->data to struct rfcomm_hdr and dereferences
hdr->addr and hdr->ctrl without validating skb->len first. A truncated
frame with skb->len less than the minimum header size causes an
out-of-bounds read of uninitialized memory. Additionally, a zero-length
frame causes skb->len-- to underflow to UINT_MAX, making
skb_tail_pointer() read far past the buffer.
Commit 23882b828c3c ("Bluetooth: RFCOMM: validate skb length in MCC
handlers") fixed the same class of missing-length-check bugs in the MCC
sub-handlers, but the top-level rfcomm_recv_frame() was left unfixed.
KMSAN reports:
BUG: KMSAN: uninit-value in rfcomm_run
...
Uninit was created at:
__alloc_skb+0x474/0xb60
vhci_write+0xe9/0x870
Fix this by rejecting frames smaller than sizeof(struct rfcomm_hdr) + 1
(the minimum frame must have a 3-byte header and a 1-byte FCS). |
| In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: flush backend after device ioctls
vhost-scsi translates guest response descriptors into userspace iovecs
when commands are submitted. Target-core completes those commands
asynchronously, so VHOST_SET_MEM_TABLE can replace the memory table while
an in-flight command still retains response iovecs translated through the
old table.
If the old mapping is reused after VHOST_SET_MEM_TABLE returns, command
completion can write the response to an unrelated userspace object.
Flush the vhost-scsi backend after vhost_dev_ioctl() handles a device
ioctl. This waits for in-flight commands that can still use the old
response iovecs before the ioctl returns. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Do not block on tag allocation in scsi_eh_lock_door()
scsi_eh_lock_door() is called from scsi_restart_operations() while the
host is still in the SHOST_RECOVERY state, i.e. before the host is
switched back to SHOST_RUNNING and scsi_run_host_queues() restarts the
queues. It allocates a request via scsi_alloc_request() with no flags,
so blk_mq_get_tag() may block waiting for a free sched tag when all tags
are already in use.
Those tags can be held by commands that were just requeued by
scsi_eh_flush_done_q() during error handling. Such commands cannot be
dispatched until the host leaves SHOST_RECOVERY and
scsi_run_host_queues() is called - which only happens *after*
scsi_eh_lock_door() returns.
This forms a circular dependency:
- scsi_eh_lock_door(), running in the SCSI error handler thread, waits
for a sched tag held by a requeued command;
- the requeued command cannot complete and release its sched tag until
the error handler thread leaves scsi_restart_operations() and restart
the queues.
For devices with a single driver tag (e.g. USB storage) it is a
guaranteed deadlock and I/O that can never be submitted. This problem
has also been reproduced in our environment.
Locking the door is a best-effort operation, and scsi_eh_lock_door()
already returns silently when the request allocation fails. Pass
BLK_MQ_REQ_NOWAIT to scsi_alloc_request() so the allocation fails
instead of blocking when no tag is available. This breaks the circular
dependency and allows the error handler to finish restarting the queues,
after which the pending commands are dispatched normally. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_log: wait for rcu grace period before freeing pernet state
sashiko reports: "nfnl_log_net_exit() calls nf_log_unset(), which
clears the logger pointer without an RCU grace period. Immediately after,
ops_free_list() frees the per-net state while concurrent packets might
still be executing nf_log_packet() under rcu_read_lock()."
Clear the pointer via .pre_exit to make sure rcu readers have completed
before pernet storage is free'd. The change in nf_log_syslog.c is only
done for consistency: it doesn't use pernet data. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: smbus: reject oversized block transfers in the common path
The SMBus block transfer length data->block[0] is validated in
i2c_smbus_xfer_emulated() but that check runs too late for tracepoints
and is skipped entirely when the adapter provides a native smbus_xfer
implementation. This allows user-controlled oversized block lengths to
reach tracepoint memcpy calls and driver callbacks unchecked.
Add an early validation in __i2c_smbus_xfer() that rejects block
transfers whose caller-supplied length is zero or exceeds
I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback
runs. data->block[0] is filled in by the device on SMBus block reads,
so the check is scoped to operations where the length is actually
supplied by the caller. This is consistent with the existing -EINVAL
convention in the emulated path and protects all downstream consumers
at once: the smbus_write tracepoint, all native smbus_xfer driver
implementations, and the emulated path.
Two distinct bugs are fixed by this change:
Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h)
trace_smbus_write() fires before any validation and copies
data->block[0]+1 bytes into a 34-byte event buffer. With
block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221.
BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530
Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91
Call Trace:
<TASK>
__asan_memcpy+0x23/0x80
trace_event_raw_event_smbus_write+0x27c/0x530
__i2c_smbus_xfer+0x43a/0xa40
i2c_smbus_xfer+0x19e/0x340
i2cdev_ioctl_smbus+0x38f/0x7f0
i2cdev_ioctl+0x35e/0x680
__x64_sys_ioctl+0x147/0x1e0
do_syscall_64+0xcf/0x15a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c)
stub_xfer() implements .smbus_xfer directly and only clamps
block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With
block[0]=0xff and command=0 the loop accesses block[1+i] for
i up to 254, far past the 34-byte union.
UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44
index 34 is out of range for type '__u8 [34]'
Call Trace:
<TASK>
__ubsan_handle_out_of_bounds+0xd7/0x120
stub_xfer+0x1971/0x198f [i2c_stub]
__i2c_smbus_xfer+0x306/0xa40
i2c_smbus_xfer+0x19e/0x340
i2cdev_ioctl_smbus+0x38f/0x7f0
i2cdev_ioctl+0x35e/0x680
__x64_sys_ioctl+0x147/0x1e0
do_syscall_64+0xcf/0x15a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN. |
| In the Linux kernel, the following vulnerability has been resolved:
net: appletalk: fix NULL pointer dereference in aarp_send_ddp()
aarp_send_ddp() calls atalk_find_dev_addr(dev) in the LocalTalk fast
path without checking for NULL. When the device has no AppleTalk
interface configured (dev->atalk_ptr == NULL), this leads to a NULL
pointer dereference at the at->s_net access.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:aarp_send_ddp (net/appletalk/aarp.c:552 (discriminator 2))
Call Trace:
<TASK>
atalk_sendmsg (net/appletalk/ddp.c:1715)
__sys_sendto (net/socket.c:2265 (discriminator 1))
__x64_sys_sendto (net/socket.c:2272)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Add a NULL check consistent with the other callers of
atalk_find_dev_addr(). |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: embed f2fs_gc_kthread in f2fs_sb_info
Instead of allocating f2fs_gc_kthread dynamically, embed it in
f2fs_sb_info. This simplifies lifetime management and prepares for
fixing race conditions during teardown.
- __sbi_store - remount|shutdown
- f2fs_stop_gc_thread
- access sbi->gc_thread
- sbi->gc_thread = NULL
- access sbi->gc_thread->f2fs_gc_task |
| In the Linux kernel, the following vulnerability has been resolved:
drm/pagemap: dma-unmap pages before handling migration errors
drm_pagemap_migrate_unmap_pages() relies on the pages array to determine
which pages require DMA unmapping. However,
drm_pagemap_migration_unlock_put_pages() clears the array as part of its
cleanup, leaving drm_pagemap_migrate_unmap_pages() with no valid page
information if it is called afterward.
Call drm_pagemap_migrate_unmap_pages() before
drm_pagemap_migration_unlock_put_pages() so the pages array remains
valid during DMA unmapping. |
| Termix is a web-based server management platform with SSH terminal, tunneling, and file editing capabilities. From 1.7.0 until 2.5.1, Termix derives the keys that wrap OIDC and WebAuthn users' Data Encryption Keys from committed default strings and the public userId salt in src/backend/utils/user-crypto.ts. Because OIDC_SYSTEM_SECRET and WEBAUTHN_SYSTEM_SECRET are not configured by the project's default deployment artifacts, an attacker with an offline SQLite database copy can derive the wrapping key, recover each affected user's DEK, and decrypt stored SSH passwords, private keys, and key passphrases. Password-authenticated users are not affected by this specific key derivation path. This issue is fixed in version 2.5.1. |
