Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-39898 (GCVE-0-2025-39898)
Vulnerability from cvelistv5 – Published: 2025-10-01 07:42 – Updated: 2025-10-24 11:41This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Show details on NVD website{
"containers": {
"cna": {
"providerMetadata": {
"dateUpdated": "2025-10-24T11:41:53.958Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"rejectedReasons": [
{
"lang": "en",
"value": "This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39898",
"datePublished": "2025-10-01T07:42:46.360Z",
"dateRejected": "2025-10-24T11:41:53.958Z",
"dateReserved": "2025-04-16T07:20:57.146Z",
"dateUpdated": "2025-10-24T11:41:53.958Z",
"state": "REJECTED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"nvd": {
"cve": {
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority."
}
],
"id": "CVE-2025-39898",
"lastModified": "2025-10-24T12:15:37.597",
"metrics": {},
"published": "2025-10-01T08:15:32.483",
"references": [],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Rejected"
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-30T01:24:24+00:00",
"cve": "CVE-2025-39898",
"id": "CVE-2025-39898",
"initial_release_date": "2025-10-01T00:00:00+00:00",
"product_status:fixed": "2252",
"product_status:known_affected": "22",
"product_status:known_not_affected": "14",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: e1000e: fix heap overflow in e1000_set_eeprom",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-39898.json",
"version": "3"
}
}
}
OESA-2025-2555 (CVE-2022-50306)
Vulnerability from osv_openeuler – Published: 2025-10-31 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential out of bound read in ext4_fc_replay_scan()
For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read.(CVE-2022-50306)
In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)
In the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk->rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.pabeni@redhat.com: fixed commit message typo
In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK>Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)
In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device->pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)
In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)
In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field &msg->msg[msg->curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 drm_display_helper
In the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st->ts_input, however, the err label can be reached before theallocated iio_dev is stored to st->ts_input. Thus callinput_free_device() on input instead of st->ts_input.(CVE-2024-57904)
In the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)
In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)
In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)
In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.kwilczynski: commit log
In the Linux kernel, the following vulnerability has been resolved:
bpf: consider that tail calls invalidate packet pointers
Tail-called programs could execute any of the helpers that invalidate packet pointers. Hence, conservatively assume that each tail call invalidates packet pointers.
Making the change in bpf_helper_changes_pkt_data() automatically makes use of check_cfg() logic that computes 'changes_pkt_data' effect for global sub-programs, such that the following program could be rejected:
int tail_call(struct __sk_buff *sk)
{
bpf_tail_call_static(sk, &jmp_table, 0);
return 0;
}
SEC("tc")
int not_safe(struct __sk_buff *sk)
{
int *p = (void *)(long)sk->data;
... make p valid ...
tail_call(sk);
*p = 42; /* this is unsafe */
...
}
The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that can invalidate packet pointers. Otherwise, it can't be freplaced with tailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)
In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)
In the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix oops when unload drivers paralleling
When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops.
But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock.
To fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)
In the Linux kernel, the following vulnerability has been resolved:
sctp: detect and prevent references to a freed transport in sendmsg
sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent.
There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf().
This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read.
This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").
Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process.
If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send.
The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).(CVE-2025-23142)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.(CVE-2025-37823)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: drr: Fix double list add in class with netem as child qdisc
As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.
In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before adding to the list to cover for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: Flush gso_skb list too during ->change()
Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen.
This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.(CVE-2025-37992)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()
Lei Lu recently reported that nfsd4_setclientid_confirm() did not check the return value from get_client_locked(). a SETCLIENTID_CONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.
Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.
In the case where the unconfirmed client is expiring, just fail and return the result from get_client_locked().(CVE-2025-38724)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)
In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"perf-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-287.0.0.190.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"perf-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-287.0.0.190.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential out of bound read in ext4_fc_replay_scan()\n\nFor scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain\nspace less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read\nwhen mounting corrupt file system image.\nADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this\nthree tags will read data during scan, tag length couldn\u0026apos;t less than data length\nwhich will read.(CVE-2022-50306)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig-\u0026gt;posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig-\u0026gt;posix_timer_id \u0026lt; 0) start = sig-\u0026gt;posix_timer_id; sig-\u0026gt;posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig-\u0026gt;posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk-\u0026gt;rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.[pabeni@redhat.com: fixed commit message typo](CVE-2024-50210)\n\nIn the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 \u0026lt;/TASK\u0026gt;Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: \u0026lt;TASK\u0026gt; ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field \u0026amp;msg-\u0026gt;msg[msg-\u0026gt;curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper](CVE-2024-56616)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st-\u0026gt;ts_input, however, the err label can be reached before theallocated iio_dev is stored to st-\u0026gt;ts_input. Thus callinput_free_device() on input instead of st-\u0026gt;ts_input.(CVE-2024-57904)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)\n\nIn the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)\n\nIn the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link-\u0026gt;downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log](CVE-2024-58093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: consider that tail calls invalidate packet pointers\n\nTail-called programs could execute any of the helpers that invalidate\npacket pointers. Hence, conservatively assume that each tail call\ninvalidates packet pointers.\n\nMaking the change in bpf_helper_changes_pkt_data() automatically makes\nuse of check_cfg() logic that computes \u0026apos;changes_pkt_data\u0026apos; effect for\nglobal sub-programs, such that the following program could be\nrejected:\n\n int tail_call(struct __sk_buff *sk)\n {\n \tbpf_tail_call_static(sk, \u0026amp;jmp_table, 0);\n \treturn 0;\n }\n\n SEC(\u0026quot;tc\u0026quot;)\n int not_safe(struct __sk_buff *sk)\n {\n \tint *p = (void *)(long)sk-\u0026gt;data;\n \t... make p valid ...\n \ttail_call(sk);\n \t*p = 42; /* this is unsafe */\n \t...\n }\n\nThe tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that\ncan invalidate packet pointers. Otherwise, it can\u0026apos;t be freplaced with\ntailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)\n\nIn the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)\n\nIn the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix oops when unload drivers paralleling\n\nWhen unload hclge driver, it tries to disable sriov first for each\nae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at\nthe time, because it removes all the ae_dev nodes, and it may cause\noops.\n\nBut we can\u0026apos;t simply use hnae3_common_lock for this. Because in the\nprocess flow of pci_disable_sriov(), it will trigger the remove flow\nof VF, which will also take hnae3_common_lock.\n\nTo fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: detect and prevent references to a freed transport in sendmsg\n\nsctp_sendmsg() re-uses associations and transports when possible by\ndoing a lookup based on the socket endpoint and the message destination\naddress, and then sctp_sendmsg_to_asoc() sets the selected transport in\nall the message chunks to be sent.\n\nThere\u0026apos;s a possible race condition if another thread triggers the removal\nof that selected transport, for instance, by explicitly unbinding an\naddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have\nbeen set up and before the message is sent. This can happen if the send\nbuffer is full, during the period when the sender thread temporarily\nreleases the socket lock in sctp_wait_for_sndbuf().\n\nThis causes the access to the transport data in\nsctp_outq_select_transport(), when the association outqueue is flushed,\nto result in a use-after-free read.\n\nThis change avoids this scenario by having sctp_transport_free() signal\nthe freeing of the transport, tagging it as \u0026quot;dead\u0026quot;. In order to do this,\nthe patch restores the \u0026quot;dead\u0026quot; bit in struct sctp_transport, which was\nremoved in\ncommit 47faa1e4c50e (\u0026quot;sctp: remove the dead field of sctp_transport\u0026quot;).\n\nThen, in the scenario where the sender thread has released the socket\nlock in sctp_wait_for_sndbuf(), the bit is checked again after\nre-acquiring the socket lock to detect the deletion. This is done while\nholding a reference to the transport to prevent it from being freed in\nthe process.\n\nIf the transport was deleted while the socket lock was relinquished,\nsctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the\nsend.\n\nThe bug was found by a private syzbot instance (see the error report [1]\nand the C reproducer that triggers it [2]).(CVE-2025-23142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too\n\nSimilarly to the previous patch, we need to safe guard hfsc_dequeue()\ntoo. But for this one, we don\u0026apos;t have a reliable reproducer.(CVE-2025-37823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: drr: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc\u0026apos;s enqueue callback reentrant.\nIn the case of drr, there won\u0026apos;t be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether the\nclass was already added to the active_list (cl_is_active) before adding\nto the list to cover for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: Flush gso_skb list too during -\u0026gt;change()\n\nPreviously, when reducing a qdisc\u0026apos;s limit via the -\u0026gt;change() operation, only\nthe main skb queue was trimmed, potentially leaving packets in the gso_skb\nlist. This could result in NULL pointer dereference when we only check\nsch-\u0026gt;limit against sch-\u0026gt;q.qlen.\n\nThis patch introduces a new helper, qdisc_dequeue_internal(), which ensures\nboth the gso_skb list and the main queue are properly flushed when trimming\nexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)\nare updated to use this helper in their -\u0026gt;change() routines.(CVE-2025-37992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()\n\nLei Lu recently reported that nfsd4_setclientid_confirm() did not check\nthe return value from get_client_locked(). a SETCLIENTID_CONFIRM could\nrace with a confirmed client expiring and fail to get a reference. That\ncould later lead to a UAF.\n\nFix this by getting a reference early in the case where there is an\nextant confirmed client. If that fails then treat it as if there were no\nconfirmed client found at all.\n\nIn the case where the unconfirmed client is expiring, just fail and\nreturn the result from get_client_locked().(CVE-2025-38724)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)\n\nIn the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf-\u0026gt;ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)",
"id": "OESA-2025-2555",
"modified": "2026-08-06T11:09:38Z",
"published": "2025-10-31T11:09:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2555"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50306"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57906"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21665"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-50306",
"CVE-2023-53728",
"CVE-2024-50210",
"CVE-2024-53168",
"CVE-2024-53214",
"CVE-2024-56602",
"CVE-2024-56616",
"CVE-2024-57904",
"CVE-2024-57906",
"CVE-2024-57931",
"CVE-2024-58052",
"CVE-2024-58093",
"CVE-2024-58237",
"CVE-2025-21665",
"CVE-2025-21772",
"CVE-2025-21802",
"CVE-2025-23142",
"CVE-2025-37823",
"CVE-2025-37915",
"CVE-2025-37992",
"CVE-2025-38724",
"CVE-2025-39898",
"CVE-2025-39971",
"CVE-2025-39998"
]
}
OESA-2025-2556 (CVE-2024-53168)
Vulnerability from osv_openeuler – Published: 2025-10-31 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK>Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)
In the Linux kernel, the following vulnerability has been resolved:
x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()
Xen doesn't offer MSR_FAM10H_MMIO_CONF_BASE to all guests. This results in the following warning:
unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0) Call Trace: xen_read_msr+0x1e/0x30 amd_get_mmconfig_range+0x2b/0x80 quirk_amd_mmconfig_area+0x28/0x100 pnp_fixup_device+0x39/0x50 __pnp_add_device+0xf/0x150 pnp_add_device+0x3d/0x100 pnpacpi_add_device_handler+0x1f9/0x280 acpi_ns_get_device_callback+0x104/0x1c0 acpi_ns_walk_namespace+0x1d0/0x260 acpi_get_devices+0x8a/0xb0 pnpacpi_init+0x50/0x80 do_one_initcall+0x46/0x2e0 kernel_init_freeable+0x1da/0x2f0 kernel_init+0x16/0x1b0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30
based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the right course of action, so no change is needed there.
This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe.(CVE-2025-21913)
In the Linux kernel, the following vulnerability has been resolved:
pds_core: Prevent possible adminq overflow/stuck condition
The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion.
On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW.
As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16.(CVE-2025-37987)
In the Linux kernel, the following vulnerability has been resolved:
module: ensure that kobject_put() is safe for module type kobjects
In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.(CVE-2025-37995)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: fix NULL dereference on unbind due to stale coupling data
Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind.
This can happen during runtime PM or other regulator operations that rely on coupling metadata.
For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state.
Ensure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().
When the nvif_vmm_type is invalid, we will return error directly without freeing the args in nvif_vmm_ctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: fix panic due to PSLVERR
When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled.
In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition.
When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle().
Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue.
Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70(CVE-2025-39724)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()
A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it.
Below is the KASAN splat after the out of bounds access happens:
[ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] <TASK> [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 ...
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)
In the Linux kernel, the following vulnerability has been resolved:
fbcon: fix integer overflow in fbcon_do_set_font
Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters.
The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.
Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation.(CVE-2025-39967)
In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn->state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 </TASK>Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 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/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)
In the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-source-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"perf-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"python3-perf-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-114.0.0.106.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-source-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"perf-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"python3-perf-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-114.0.0.106.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-114.0.0.106.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 \u0026lt;/TASK\u0026gt;Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()\n\nXen doesn\u0026apos;t offer MSR_FAM10H_MMIO_CONF_BASE to all guests. This results\nin the following warning:\n\n unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0)\n Call Trace:\n xen_read_msr+0x1e/0x30\n amd_get_mmconfig_range+0x2b/0x80\n quirk_amd_mmconfig_area+0x28/0x100\n pnp_fixup_device+0x39/0x50\n __pnp_add_device+0xf/0x150\n pnp_add_device+0x3d/0x100\n pnpacpi_add_device_handler+0x1f9/0x280\n acpi_ns_get_device_callback+0x104/0x1c0\n acpi_ns_walk_namespace+0x1d0/0x260\n acpi_get_devices+0x8a/0xb0\n pnpacpi_init+0x50/0x80\n do_one_initcall+0x46/0x2e0\n kernel_init_freeable+0x1da/0x2f0\n kernel_init+0x16/0x1b0\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1b/0x30\n\nbased on quirks for a \u0026quot;PNP0c01\u0026quot; device. Treating MMCFG as disabled is the\nright course of action, so no change is needed there.\n\nThis was most likely exposed by fixing the Xen MSR accessors to not be\nsilently-safe.(CVE-2025-21913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: Prevent possible adminq overflow/stuck condition\n\nThe pds_core\u0026apos;s adminq is protected by the adminq_lock, which prevents\nmore than 1 command to be posted onto it at any one time. This makes it\nso the client drivers cannot simultaneously post adminq commands.\nHowever, the completions happen in a different context, which means\nmultiple adminq commands can be posted sequentially and all waiting\non completion.\n\nOn the FW side, the backing adminq request queue is only 16 entries\nlong and the retry mechanism and/or overflow/stuck prevention is\nlacking. This can cause the adminq to get stuck, so commands are no\nlonger processed and completions are no longer sent by the FW.\n\nAs an initial fix, prevent more than 16 outstanding adminq commands so\nthere\u0026apos;s no way to cause the adminq from getting stuck. This works\nbecause the backing adminq request queue will never have more than 16\npending adminq commands, so it will never overflow. This is done by\nreducing the adminq depth to 16.(CVE-2025-37987)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmodule: ensure that kobject_put() is safe for module type kobjects\n\nIn \u0026apos;lookup_or_create_module_kobject()\u0026apos;, an internal kobject is created\nusing \u0026apos;module_ktype\u0026apos;. So call to \u0026apos;kobject_put()\u0026apos; on error handling\npath causes an attempt to use an uninitialized completion pointer in\n\u0026apos;module_kobject_release()\u0026apos;. In this scenario, we just want to release\nkobject without an extra synchronization required for a regular module\nunloading process, so adding an extra check whether \u0026apos;complete()\u0026apos; is\nactually required makes \u0026apos;kobject_put()\u0026apos; safe.(CVE-2025-37995)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: fix NULL dereference on unbind due to stale coupling data\n\nFailing to reset coupling_desc.n_coupled after freeing coupled_rdevs can\nlead to NULL pointer dereference when regulators are accessed post-unbind.\n\nThis can happen during runtime PM or other regulator operations that rely\non coupling metadata.\n\nFor example, on ridesx4, unbinding the \u0026apos;reg-dummy\u0026apos; platform device triggers\na panic in regulator_lock_recursive() due to stale coupling state.\n\nEnsure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().\n\nWhen the nvif_vmm_type is invalid, we will return error directly\nwithout freeing the args in nvif_vmm_ctor(), which leading a memory\nleak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250: fix panic due to PSLVERR\n\nWhen the PSLVERR_RESP_EN parameter is set to 1, the device generates\nan error response if an attempt is made to read an empty RBR (Receive\nBuffer Register) while the FIFO is enabled.\n\nIn serial8250_do_startup(), calling serial_port_out(port, UART_LCR,\nUART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes\ndw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter\nfunction enables the FIFO via serial_out(p, UART_FCR, p-\u0026gt;fcr).\nExecution proceeds to the serial_port_in(port, UART_RX).\nThis satisfies the PSLVERR trigger condition.\n\nWhen another CPU (e.g., using printk()) is accessing the UART (UART\nis busy), the current CPU fails the check (value \u0026amp; ~UART_LCR_SPAR) ==\n(lcr \u0026amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter\ndw8250_force_idle().\n\nPut serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-\u0026gt;lock\nto fix this issue.\n\nPanic backtrace:\n[ 0.442336] Oops - unknown exception [#1]\n[ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a\n[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e\n...\n[ 0.442416] console_on_rootfs+0x26/0x70(CVE-2025-39724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: fix slab out-of-bounds access in mt_report_fixup()\n\nA malicious HID device can trigger a slab out-of-bounds during\nmt_report_fixup() by passing in report descriptor smaller than\n607 bytes. mt_report_fixup() attempts to patch byte offset 607\nof the descriptor with 0x25 by first checking if byte offset\n607 is 0x15 however it lacks bounds checks to verify if the\ndescriptor is big enough before conducting this check. Fix\nthis bug by ensuring the descriptor size is at least 608\nbytes before accessing it.\n\nBelow is the KASAN splat after the out of bounds access happens:\n\n[ 13.671954] ==================================================================\n[ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110\n[ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10\n[ 13.673297]\n[ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3\n[ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04\n[ 13.673297] Call Trace:\n[ 13.673297] \u0026lt;TASK\u0026gt;\n[ 13.673297] dump_stack_lvl+0x5f/0x80\n[ 13.673297] print_report+0xd1/0x660\n[ 13.673297] kasan_report+0xe5/0x120\n[ 13.673297] __asan_report_load1_noabort+0x18/0x20\n[ 13.673297] mt_report_fixup+0x103/0x110\n[ 13.673297] hid_open_report+0x1ef/0x810\n[ 13.673297] mt_probe+0x422/0x960\n[ 13.673297] hid_device_probe+0x2e2/0x6f0\n[ 13.673297] really_probe+0x1c6/0x6b0\n[ 13.673297] __driver_probe_device+0x24f/0x310\n[ 13.673297] driver_probe_device+0x4e/0x220\n[ 13.673297] __device_attach_driver+0x169/0x320\n[ 13.673297] bus_for_each_drv+0x11d/0x1b0\n[ 13.673297] __device_attach+0x1b8/0x3e0\n[ 13.673297] device_initial_probe+0x12/0x20\n[ 13.673297] bus_probe_device+0x13d/0x180\n[ 13.673297] device_add+0xe3a/0x1670\n[ 13.673297] hid_add_device+0x31d/0xa40\n[...](CVE-2025-39806)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: fix integer overflow in fbcon_do_set_font\n\nFix integer overflow vulnerabilities in fbcon_do_set_font() where font\nsize calculations could overflow when handling user-controlled font\nparameters.\n\nThe vulnerabilities occur when:\n1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount\n multiplication with user-controlled values that can overflow.\n2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow\n3. This results in smaller allocations than expected, leading to buffer\n overflows during font data copying.\n\nAdd explicit overflow checking using check_mul_overflow() and\ncheck_add_overflow() kernel helpers to safety validate all size\ncalculations before allocation.(CVE-2025-39967)\n\nIn the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn-\u0026gt;state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 \u0026lt;/TASK\u0026gt;Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 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/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)\n\nIn the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx-\u0026gt;users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)\n\nIn the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)",
"id": "OESA-2025-2556",
"modified": "2026-08-06T11:09:38Z",
"published": "2025-10-31T11:09:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37987"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38668"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39679"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40019"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-53168",
"CVE-2025-21913",
"CVE-2025-37987",
"CVE-2025-37995",
"CVE-2025-38668",
"CVE-2025-39679",
"CVE-2025-39724",
"CVE-2025-39806",
"CVE-2025-39898",
"CVE-2025-39967",
"CVE-2025-39982",
"CVE-2025-39993",
"CVE-2025-39998",
"CVE-2025-40019"
]
}
OPENSUSE-SU-2025:20081-1
Vulnerability from csaf_opensuse - Published: 2025-11-25 07:35 - Updated: 2026-09-20 21:47RHSA-2025:21933
Vulnerability from csaf_opensuse - Published: 2025-11-24 00:00 - Updated: 2026-09-20 11:51RHSA-2025:22388
Vulnerability from csaf_opensuse - Published: 2025-12-01 00:00 - Updated: 2026-09-20 11:51RHSA-2025:22395
Vulnerability from csaf_opensuse - Published: 2025-12-01 00:00 - Updated: 2026-09-20 11:51RHSA-2025:22405
Vulnerability from csaf_opensuse - Published: 2025-12-01 00:00 - Updated: 2026-09-20 11:51RHSA-2025:22387
Vulnerability from csaf_redhat - Published: 2025-12-01 05:31 - Updated: 2026-07-30 08:47A heap‑overflow vulnerability was discovered in the linux kernel e1000e driver’s e1000_set_eeprom() function, insufficient validation of the requested length for an EEPROM change could allow a local, low‑privilege user to trigger memory corruption (heap overflow). A local unprivileged user with access to the driver could exploit this flaw to cause memory corruption, potentially leading to confidentiality, integrity, and availability damage.
RHSA-2025:22571
Vulnerability from csaf_redhat - Published: 2025-12-02 11:12 - Updated: 2026-07-30 08:53A heap‑overflow vulnerability was discovered in the linux kernel e1000e driver’s e1000_set_eeprom() function, insufficient validation of the requested length for an EEPROM change could allow a local, low‑privilege user to trigger memory corruption (heap overflow). A local unprivileged user with access to the driver could exploit this flaw to cause memory corruption, potentially leading to confidentiality, integrity, and availability damage.
RHSA-2026:0489
Vulnerability from csaf_redhat - Published: 2026-01-13 09:50 - Updated: 2026-09-24 21:50A heap‑overflow vulnerability was discovered in the linux kernel e1000e driver’s e1000_set_eeprom() function, insufficient validation of the requested length for an EEPROM change could allow a local, low‑privilege user to trigger memory corruption (heap overflow). A local unprivileged user with access to the driver could exploit this flaw to cause memory corruption, potentially leading to confidentiality, integrity, and availability damage.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.