| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal
CXL is linked before fwctl in drivers/Makefile. Both use `module_init, so
`cxl_pci_driver_init()` runs first. When `cxl_pci_probe()` calls
`fwctl_register()` and then `device_add()`, fwctl_class is not yet
registered because fwctl_init() hasn't run, causing `class_to_subsys()` to
return NULL and skip knode_class initialization.
On device removal, `class_to_subsys()` returns non-NULL, and
`device_del()` calls `klist_del()` on the uninitialized knode, triggering
a NULL pointer dereference. |
| In the Linux kernel, the following vulnerability has been resolved:
net: psp: require admin permission for dev-set and key-rotate
The dev-set and key-rotate netlink operations modify shared device
state (PSP version configuration and cryptographic key material,
respectively) but do not require CAP_NET_ADMIN. The only access
control is psp_dev_check_access() which merely verifies netns
membership. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: avoid double drm_exec_fini() in userq validate
When new_addition is true, amdgpu_userq_vm_validate() calls
drm_exec_fini(&exec) before iterating over the collected HMM ranges and
calling amdgpu_ttm_tt_get_user_pages().
If amdgpu_ttm_tt_get_user_pages() fails in that path, the code jumps to
unlock_all and calls drm_exec_fini(&exec) a second time on the same
exec object. drm_exec_fini() is not idempotent: it frees exec->objects
and may also drop exec->contended and finalize the ww acquire context.
Route that error path directly to the range cleanup once exec has
already been finalized.
Issue found using a prototype static analysis tool
and confirmed by code review.
(cherry picked from commit 2802952e4a07306da6ebe813ff1acacc5691851a) |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers
Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds
PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue)
and returns early. However, because the function returns void, the
callers are entirely unaware that a fatal error has occurred and
that the cmd->recv_msg.msg_iter was left uninitialized.
Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly
overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA
Consequently, the socket receiving loop may attempt to read incoming
network data into the uninitialized iterator.
Fix this by shifting the error handling responsibility to the callers. |
| In the Linux kernel, the following vulnerability has been resolved:
fsnotify: fix inode reference leak in fsnotify_recalc_mask()
fsnotify_recalc_mask() fails to handle the return value of
__fsnotify_recalc_mask(), which may return an inode pointer that needs
to be released via fsnotify_drop_object() when the connector's HAS_IREF
flag transitions from set to cleared.
This manifests as a hung task with the following call trace:
INFO: task umount:1234 blocked for more than 120 seconds.
Call Trace:
__schedule
schedule
fsnotify_sb_delete
generic_shutdown_super
kill_anon_super
cleanup_mnt
task_work_run
do_exit
do_group_exit
The race window that triggers the iref leak:
Thread A (adding mark) Thread B (removing mark)
────────────────────── ────────────────────────
fsnotify_add_mark_locked():
fsnotify_add_mark_list():
spin_lock(conn->lock)
add mark_B(evictable) to list
spin_unlock(conn->lock)
return
/* ---- gap: no lock held ---- */
fsnotify_detach_mark(mark_A):
spin_lock(mark_A->lock)
clear ATTACHED flag on mark_A
spin_unlock(mark_A->lock)
fsnotify_put_mark(mark_A)
fsnotify_recalc_mask():
spin_lock(conn->lock)
__fsnotify_recalc_mask():
/* mark_A skipped: ATTACHED cleared */
/* only mark_B(evictable) remains */
want_iref = false
has_iref = true /* not yet cleared */
-> HAS_IREF transitions true -> false
-> returns inode pointer
spin_unlock(conn->lock)
/* BUG: return value discarded!
* iput() and fsnotify_put_sb_watched_objects()
* are never called */
Fix this by deferring the transition true -> false of HAS_IREF flag from
fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B). |
| In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: fix deadlock in hid_post_reset()
You can build a USB device that includes a HID component
and a storage or UAS component. The components can be reset
only together. That means that hid_pre_reset() and hid_post_reset()
are in the block IO error handling. Hence no memory allocation
used in them may do block IO because the IO can deadlock
on the mutex held while resetting a device and calling the
interface drivers.
Use GFP_NOIO for all allocations in them. |
| In the Linux kernel, the following vulnerability has been resolved:
ima_fs: Correctly create securityfs files for unsupported hash algos
ima_tpm_chip->allocated_banks[i].crypto_id is initialized to
HASH_ALGO__LAST if the TPM algorithm is not supported. However there
are places relying on the algorithm to be valid because it is accessed
by hash_algo_name[].
On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
==================================================================
BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
Call Trace:
<TASK>
dump_stack_lvl+0x61/0x90
print_report+0xc4/0x580
? kasan_addr_to_slab+0x26/0x80
? create_securityfs_measurement_lists+0x396/0x440
kasan_report+0xc2/0x100
? create_securityfs_measurement_lists+0x396/0x440
create_securityfs_measurement_lists+0x396/0x440
ima_fs_init+0xa3/0x300
ima_init+0x7d/0xd0
init_ima+0x28/0x100
do_one_initcall+0xa6/0x3e0
kernel_init_freeable+0x455/0x740
kernel_init+0x24/0x1d0
ret_from_fork+0x38/0x80
ret_from_fork_asm+0x11/0x20
</TASK>
The buggy address belongs to the variable:
hash_algo_name+0xb8/0x420
Memory state around the buggy address:
ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
^
ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
==================================================================
Seems like the TPM chip supports sha3_256, which isn't yet in
tpm_algorithms:
tpm tpm0: TPM with unsupported bank algorithm 0x0027
That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0
Library Part 2: Structures", page 51 [1].
See also the related U-Boot algorithms update [2].
Thus solve the problem by creating a file name with "_tpm_alg_<ID>"
postfix if the crypto algorithm isn't initialized.
This is how it looks on the test machine (patch ported to v6.12 release):
# ls -1 /sys/kernel/security/ima/
ascii_runtime_measurements
ascii_runtime_measurements_tpm_alg_27
ascii_runtime_measurements_sha1
ascii_runtime_measurements_sha256
binary_runtime_measurements
binary_runtime_measurements_tpm_alg_27
binary_runtime_measurements_sha1
binary_runtime_measurements_sha256
policy
runtime_measurements_count
violations
[1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf
[2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate group add input before caching
[BUG]
OCFS2_IOC_GROUP_ADD can trigger a BUG_ON in
ocfs2_set_new_buffer_uptodate():
kernel BUG at fs/ocfs2/uptodate.c:509!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c:509
Code: ffffe88f 42b9fe4c 89e64889 dfe8b4df
Call Trace:
ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c:507
ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c:887
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+0x197/0x1e0 fs/ioctl.c:583
x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7bbfb55a966d
[CAUSE]
ocfs2_group_add() calls ocfs2_set_new_buffer_uptodate() on a
user-controlled group block before ocfs2_verify_group_and_input()
validates that block number. That helper is only valid for newly
allocated metadata and asserts that the block is not already present in
the chosen metadata cache. The code also uses INODE_CACHE(inode) even
though the group descriptor belongs to main_bm_inode and later journal
accesses use that cache context instead.
[FIX]
Validate the on-disk group descriptor before caching it, then add it to
the metadata cache tracked by INODE_CACHE(main_bm_inode). Keep the
validation failure path separate from the later cleanup path so we only
remove the buffer from that cache after it has actually been inserted.
This keeps the group buffer lifetime consistent across validation,
journaling, and cleanup. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure
Apply the same fix as b2ed01e7ad ("drm/ttm: Fix ttm_bo_swapout()
infinite LRU walk on swapout failure") to the ttm_bo_shrink() path.
Move del_bulk_move from before the backup to after success only,
using ttm_resource_del_bulk_move_unevictable() since the resource
is now unevictable once fully backed up. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: Fix error pointer dereference
The variable tps->partner is checked for an error pointer and then if it
is, it sends an error message but does not return and then immediately
dereferenced a few lines below:
tps->partner = typec_register_partner(tps->port, &desc);
if (IS_ERR(tps->partner))
dev_warn(tps->dev, "%s: failed to register partnet\n", __func__);
if (desc.identity) {
typec_partner_set_identity(tps->partner);
cd321x->cur_partner_identity = st.partner_identity;
}
Add early return and fix spelling mistake in error message.
Detected by Smatch:
drivers/usb/typec/tipd/core.c:827 cd321x_update_work() error:
'tps->partner' dereferencing possible ERR_PTR() |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: prevent uninitialized lcn caused by zero len
syzbot reported a uninit-value in ntfs_iomap_begin [1].
Since runs was not touched yet, run_lookup_entry() immediately fails
and returns false, which makes the value of "*len" 0.
Simultaneously, the new value and err value are also 0, causing the
logic in attr_data_get_block_locked() to jump directly to ok, ultimately
resulting in *lcn being triggered before it is set [1].
In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward
to before updating lcn to avoid this [1].
[1]
BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825
ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825
iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110
Local variable lcn created at:
ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786 |
| In the Linux kernel, the following vulnerability has been resolved:
i3c: master: renesas: Fix memory leak in renesas_i3c_i3c_xfers()
The xfer structure allocated by renesas_i3c_alloc_xfer() was never freed
in the renesas_i3c_i3c_xfers() function. Use the __free(kfree) cleanup
attribute to automatically free the memory when the variable goes out of
scope. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix NULL deref in map_kptr_match_type for scalar regs
Commit ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local
kptr") refactored map_kptr_match_type() to branch on btf_is_kernel()
before checking base_type(). A scalar register stored into a kptr
slot has no btf, so the btf_is_kernel(reg->btf) call dereferences
NULL.
Move the base_type() != PTR_TO_BTF_ID guard before any reg->btf
access. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nat: use kfree_rcu to release ops
Florian Westphal says:
"Historically this is not an issue, even for normal base hooks: the data
path doesn't use the original nf_hook_ops that are used to register the
callbacks.
However, in v5.14 I added the ability to dump the active netfilter
hooks from userspace.
This code will peek back into the nf_hook_ops that are available
at the tail of the pointer-array blob used by the datapath.
The nat hooks are special, because they are called indirectly from
the central nat dispatcher hook. They are currently invisible to
the nfnl hook dump subsystem though.
But once that changes the nat ops structures have to be deferred too."
Update nf_nat_register_fn() to deal with partial exposition of the hooks
from error path which can be also an issue for nfnetlink_hook. |
| In the Linux kernel, the following vulnerability has been resolved:
um: Fix potential race condition in TLB sync
During the TLB sync, we need to traverse and modify the page table,
so we should hold the page table lock. Since full SMP support for
threads within the same process is still missing, let's disable the
split page table lock for simplicity. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: target: core: Fix integer overflow in UNMAP bounds check
sbc_execute_unmap() checks LBA + range does not exceed the device capacity,
but does not guard against LBA + range wrapping around on 64-bit overflow.
Add an overflow check matching the pattern already used for WRITE_SAME in
the same file. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: terminate the cached volume label after UTF-8 conversion
ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s()
and stores the result in sbi->volume.label. The converted label is later
exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only
returns the number of bytes written and does not add a trailing NUL.
If the converted label fills the entire fixed buffer,
ntfs3_label_show() can read past the end of sbi->volume.label while
looking for a terminator.
Terminate the cached label explicitly after a successful conversion and
clamp the exact-full case to the last byte of the buffer. |
| In the Linux kernel, the following vulnerability has been resolved:
greybus: raw: fix use-after-free if write is called after disconnect
If a user writes to the chardev after disconnect has been called, the
kernel panics with the following trace (with
CONFIG_INIT_ON_FREE_DEFAULT_ON=y):
BUG: kernel NULL pointer dereference, address: 0000000000000218
...
Call Trace:
<TASK>
gb_operation_create_common+0x61/0x180
gb_operation_create_flags+0x28/0xa0
gb_operation_sync_timeout+0x6f/0x100
raw_write+0x7b/0xc7 [gb_raw]
vfs_write+0xcf/0x420
? task_mm_cid_work+0x136/0x220
ksys_write+0x63/0xe0
do_syscall_64+0xa4/0x290
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Disconnect calls gb_connection_destroy, which ends up freeing the
connection object. When gb_operation_sync is called in the write file
operations, its gets a freed connection as parameter and the kernel
panics.
The gb_connection_destroy cannot be moved out of the disconnect
function, as the Greybus subsystem expect all connections belonging to a
bundle to be destroyed when disconnect returns.
To prevent this bug, use a rw lock to synchronize access between write
and disconnect. This guarantees that the write function doesn't try
to use a disconnected connection. |
| In the Linux kernel, the following vulnerability has been resolved:
NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg
In nfsd4_add_rdaccess_to_wrdeleg, if fp->fi_fds[O_RDONLY] is already
set by another thread, __nfs4_file_get_access should not be called
to increment the nfs4_file access count since that was already done
by the thread that added READ access to the file. The extra fi_access
count in nfs4_file can prevent the corresponding nfsd_file from being
freed.
When stopping nfs-server service, these extra access counts trigger a
BUG in kmem_cache_destroy() that shows nfsd_file object remaining on
__kmem_cache_shutdown.
This problem can be reproduced by running the Git project's test
suite over NFS. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Cap AEAD AD length to 0x80000000
In order to prevent arithmetic overflows when checking the TX
buffer size, cap the associated data length to 0x80000000. |
