| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: avs: Do not share the name pointer between components
By sharing 'name' directly, tearing down components may lead to
use-after-free errors. Duplicate the name to avoid that.
At the same time, update the order of operations - since commit
cee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name via
config") the framework does not override component->name if set before
invoking the initializer. |
| In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: Correctly handle Rx checksum offload errors
The stmmac_rx function would previously set skb->ip_summed to
CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled
and the packet was of a known IP ethertype.
However, this logic failed to check if the hardware had actually
reported a checksum error. The hardware status, indicating a header or
payload checksum failure, was being ignored at this stage. This could
cause corrupt packets to be passed up the network stack as valid.
This patch corrects the logic by checking the `csum_none` status flag,
which is set when the hardware reports a checksum error. If this flag
is set, skb->ip_summed is now correctly set to CHECKSUM_NONE,
ensuring the kernel's network stack will perform its own validation and
properly handle the corrupt packet. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: fix hmm_pfn_to_map_order() usage
Handle the case where the hmm range partially covers a huge page (like
2M), otherwise we can potentially end up doing something nasty like
mapping memory which is outside the range, and maybe not even mapped by
the mm. Fix is based on the xe userptr code, which in a future patch
will directly use gpusvm, so needs alignment here.
v2:
- Add kernel-doc (Matt B)
- s/fls/ilog2/ (Thomas) |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: bitblit: bound-check glyph index in bit_putcs*
bit_putcs_aligned()/unaligned() derived the glyph pointer from the
character value masked by 0xff/0x1ff, which may exceed the actual font's
glyph count and read past the end of the built-in font array.
Clamp the index to the actual glyph count before computing the address.
This fixes a global out-of-bounds read reported by syzbot. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Fix epfile null pointer access after ep enable.
A race condition occurs when ffs_func_eps_enable() runs concurrently
with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset()
sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading
to a NULL pointer dereference when accessing epfile->ep in
ffs_func_eps_enable() after successful usb_ep_enable().
The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and
ffs_data_close() functions, and its modification is protected by the
spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function
is also protected by ffs->eps_lock.
Thus, add NULL pointer handling for ffs->epfiles in the
ffs_func_eps_enable() function to fix issues |
| In the Linux kernel, the following vulnerability has been resolved:
jfs: Verify inode mode when loading from disk
The inode mode loaded from corrupted disk can be invalid. Do like what
commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk")
does. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: bcsp: receive data only if registered
Currently, bcsp_recv() can be called even when the BCSP protocol has not
been registered. This leads to a NULL pointer dereference, as shown in
the following stack trace:
KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590
Call Trace:
<TASK>
hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627
tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290
tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
To prevent this, ensure that the HCI_UART_REGISTERED flag is set before
processing received data. If the protocol is not registered, return
-EUNATCH. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
Add bounds checking to prevent writes past framebuffer boundaries when
rendering text near screen edges. Return early if the Y position is off-screen
and clip image height to screen boundary. Break from the rendering loop if the
X position is off-screen. When clipping image width to fit the screen, update
the character count to match the clipped width to prevent buffer size
mismatches.
Without the character count update, bit_putcs_aligned and bit_putcs_unaligned
receive mismatched parameters where the buffer is allocated for the clipped
width but cnt reflects the original larger count, causing out-of-bounds writes. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: ensure no dirty metadata is written back for an fs with errors
[BUG]
During development of a minor feature (make sure all btrfs_bio::end_io()
is called in task context), I noticed a crash in generic/388, where
metadata writes triggered new works after btrfs_stop_all_workers().
It turns out that it can even happen without any code modification, just
using RAID5 for metadata and the same workload from generic/388 is going
to trigger the use-after-free.
[CAUSE]
If btrfs hits an error, the fs is marked as error, no new
transaction is allowed thus metadata is in a frozen state.
But there are some metadata modifications before that error, and they are
still in the btree inode page cache.
Since there will be no real transaction commit, all those dirty folios
are just kept as is in the page cache, and they can not be invalidated
by invalidate_inode_pages2() call inside close_ctree(), because they are
dirty.
And finally after btrfs_stop_all_workers(), we call iput() on btree
inode, which triggers writeback of those dirty metadata.
And if the fs is using RAID56 metadata, this will trigger RMW and queue
new works into rmw_workers, which is already stopped, causing warning
from queue_work() and use-after-free.
[FIX]
Add a special handling for write_one_eb(), that if the fs is already in
an error state, immediately mark the bbio as failure, instead of really
submitting them.
Then during close_ctree(), iput() will just discard all those dirty
tree blocks without really writing them back, thus no more new jobs for
already stopped-and-freed workqueues.
The extra discard in write_one_eb() also acts as an extra safenet.
E.g. the transaction abort is triggered by some extent/free space
tree corruptions, and since extent/free space tree is already corrupted
some tree blocks may be allocated where they shouldn't be (overwriting
existing tree blocks). In that case writing them back will further
corrupting the fs. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix uaf in proc_readdir_de()
Pde is erased from subdir rbtree through rb_erase(), but not set the node
to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()
set the erased node to EMPTY, then pde_subdir_next() will return NULL to
avoid uaf access.
We found an uaf issue while using stress-ng testing, need to run testcase
getdent and tun in the same time. The steps of the issue is as follows:
1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current
pde is tun3;
2) in the [time windows] unregister netdevice tun3 and tun2, and erase
them from rbtree. erase tun3 first, and then erase tun2. the
pde(tun2) will be released to slab;
3) continue to getdent process, then pde_subdir_next() will return
pde(tun2) which is released, it will case uaf access.
CPU 0 | CPU 1
-------------------------------------------------------------------------
traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2
sys_getdents64() |
iterate_dir() |
proc_readdir() |
proc_readdir_de() | snmp6_unregister_dev()
pde_get(de); | proc_remove()
read_unlock(&proc_subdir_lock); | remove_proc_subtree()
| write_lock(&proc_subdir_lock);
[time window] | rb_erase(&root->subdir_node, &parent->subdir);
| write_unlock(&proc_subdir_lock);
read_lock(&proc_subdir_lock); |
next = pde_subdir_next(de); |
pde_put(de); |
de = next; //UAF |
rbtree of dev_snmp6
|
pde(tun3)
/ \
NULL pde(tun2) |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: client: fix memory leak in smb3_fs_context_parse_param
The user calls fsconfig twice, but when the program exits, free() only
frees ctx->source for the second fsconfig, not the first.
Regarding fc->source, there is no code in the fs context related to its
memory reclamation.
To fix this memory leak, release the source memory corresponding to ctx
or fc before each parsing.
syzbot reported:
BUG: memory leak
unreferenced object 0xffff888128afa360 (size 96):
backtrace (crc 79c9c7ba):
kstrdup+0x3c/0x80 mm/util.c:84
smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444
BUG: memory leak
unreferenced object 0xffff888112c7d900 (size 96):
backtrace (crc 79c9c7ba):
smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629
smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438 |
| In the Linux kernel, the following vulnerability has been resolved:
can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled
This issue is similar to the vulnerability in the `mcp251x` driver,
which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume from
sleep before interface was brought up").
In the `hi311x` driver, when the device resumes from sleep, the driver
schedules `priv->restart_work`. However, if the network interface was
not previously enabled, the `priv->wq` (workqueue) is not allocated and
initialized, leading to a null pointer dereference.
To fix this, we move the allocation and initialization of the workqueue
from the `hi3110_open` function to the `hi3110_can_probe` function.
This ensures that the workqueue is properly initialized before it is
used during device resume. And added logic to destroy the workqueue
in the error handling paths of `hi3110_can_probe` and in the
`hi3110_can_remove` function to prevent resource leaks. |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: fix divide-by-zero in comedi_buf_munge()
The comedi_buf_munge() function performs a modulo operation
`async->munge_chan %= async->cmd.chanlist_len` without first
checking if chanlist_len is zero. If a user program submits a command with
chanlist_len set to zero, this causes a divide-by-zero error when the device
processes data in the interrupt handler path.
Add a check for zero chanlist_len at the beginning of the
function, similar to the existing checks for !map and
CMDF_RAWDATA flag. When chanlist_len is zero, update
munge_count and return early, indicating the data was
handled without munging.
This prevents potential kernel panics from malformed user commands. |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: parse_dfs_referrals: prevent oob on malformed input
Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS
- reply smaller than sizeof(struct get_dfs_referral_rsp)
- reply with number of referrals smaller than NumberOfReferrals in the
header
Processing of such replies will cause oob.
Return -EINVAL error on such replies to prevent oob-s. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()
The hfsplus_strcasecmp() logic can trigger the issue:
[ 117.317703][ T9855] ==================================================================
[ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490
[ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855
[ 117.319577][ T9855]
[ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)
[ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 117.319783][ T9855] Call Trace:
[ 117.319785][ T9855] <TASK>
[ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0
[ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0
[ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10
[ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0
[ 117.319816][ T9855] ? lock_release+0x4b/0x3e0
[ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40
[ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0
[ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0
[ 117.319842][ T9855] print_report+0x17e/0x7e0
[ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0
[ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0
[ 117.319862][ T9855] ? __phys_addr+0xd3/0x180
[ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490
[ 117.319876][ T9855] kasan_report+0x147/0x180
[ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490
[ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490
[ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10
[ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0
[ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470
[ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10
[ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10
[ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10
[ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510
[ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10
[ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10
[ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510
[ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0
[ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120
[ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890
[ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10
[ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0
[ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80
[ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10
[ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100
[ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150
[ 117.320034][ T9855] __lookup_slow+0x297/0x3d0
[ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10
[ 117.320045][ T9855] ? down_read+0x1ad/0x2e0
[ 117.320055][ T9855] lookup_slow+0x53/0x70
[ 117.320065][ T9855] walk_component+0x2f0/0x430
[ 117.320073][ T9855] path_lookupat+0x169/0x440
[ 117.320081][ T9855] filename_lookup+0x212/0x590
[ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10
[ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290
[ 117.320105][ T9855] ? getname_flags+0x1e5/0x540
[ 117.320112][ T9855] user_path_at+0x3a/0x60
[ 117.320117][ T9855] __x64_sys_umount+0xee/0x160
[ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10
[ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0
[ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0
[ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0
[ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07
[ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08
[ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix null-deref in agg_dequeue
To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)
when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return
value before using it, similar to the existing approach in sch_hfsc.c.
To avoid code duplication, the following changes are made:
1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static
inline function.
2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to
include/net/pkt_sched.h so that sch_qfq can reuse it.
3. Applied qdisc_peek_len in agg_dequeue to avoid crashing. |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: check the return value of pinmux_ops::get_function_name()
While the API contract in docs doesn't specify it explicitly, the
generic implementation of the get_function_name() callback from struct
pinmux_ops - pinmux_generic_get_function_name() - can fail and return
NULL. This is already checked in pinmux_check_ops() so add a similar
check in pinmux_func_name_to_selector() instead of passing the returned
pointer right down to strcmp() where the NULL can get dereferenced. This
is normal operation when adding new pinfunctions. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Check the helper function is valid in get_helper_proto
kernel test robot reported verifier bug [1] where the helper func
pointer could be NULL due to disabled config option.
As Alexei suggested we could check on that in get_helper_proto
directly. Marking tail_call helper func with BPF_PTR_POISON,
because it is unused by design.
[1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: Duplicate SPI Handling
The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI
Netlink message, which triggers the kernel function xfrm_alloc_spi().
This function is expected to ensure uniqueness of the Security Parameter
Index (SPI) for inbound Security Associations (SAs). However, it can
return success even when the requested SPI is already in use, leading
to duplicate SPIs assigned to multiple inbound SAs, differentiated
only by their destination addresses.
This behavior causes inconsistencies during SPI lookups for inbound packets.
Since the lookup may return an arbitrary SA among those with the same SPI,
packet processing can fail, resulting in packet drops.
According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA
is uniquely identified by the SPI and optionally protocol.
Reproducing the Issue Reliably:
To consistently reproduce the problem, restrict the available SPI range in
charon.conf : spi_min = 0x10000000 spi_max = 0x10000002
This limits the system to only 2 usable SPI values.
Next, create more than 2 Child SA. each using unique pair of src/dst address.
As soon as the 3rd Child SA is initiated, it will be assigned a duplicate
SPI, since the SPI pool is already exhausted.
With a narrow SPI range, the issue is consistently reproducible.
With a broader/default range, it becomes rare and unpredictable.
Current implementation:
xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.
So if two SAs have the same SPI but different destination addresses, then
they will:
a. Hash into different buckets
b. Be stored in different linked lists (byspi + h)
c. Not be seen in the same hlist_for_each_entry_rcu() iteration.
As a result, the lookup will result in NULL and kernel allows that Duplicate SPI
Proposed Change:
xfrm_state_lookup_spi_proto() does a truly global search - across all states,
regardless of hash bucket and matches SPI and proto. |
| In the Linux kernel, the following vulnerability has been resolved:
parisc: Drop WARN_ON_ONCE() from flush_cache_vmap
I have observed warning to occassionally trigger. |
