Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-37869 State: PUBLISHED Published: 2025-05-09T06:43:58.083Z Last Updated: 2025-05-26T05:22:41.057Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74) References: - https://git.kernel.org/stable/c/2ac5f466f62892a7d1ac2d1a3eb6c
it 762b7e95362170b3e13a8704f38d5e47eca4ba74) References: - https://git.kernel.org/stable/c/2ac5f466f62892a7d1ac2d1a3eb6cd14efbe2f2d - https://git.kernel.org/stable/c/dc712938aa26b001f448d5e93f59d57fa80f2dbd - https://git.kernel.org/stable/c/20659d3150f1a2a258a173fe011013178ff2a197
CVE ID: CVE-2025-37870 State: PUBLISHED Published: 2025-05-09T06:43:59.074Z Last Updated: 2025-09-03T13:06:50.395Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: prevent hang on link training fail [Why] When link training fails, the phy clock will be disabled. However, in enable_streams, it is assumed that link training succeeded and the mux selects the phy clock, causing a hang when a register write is made. [How] When enable_stream is hit, check if link training failed. If it did, fall back to the ref clock to avoid a hang and keep the system in a recoverable state. References: - https://git.kernel.org/stable
to the ref clock to avoid a hang and keep the system in a recoverable state. References: - https://git.kernel.org/stable/c/0363c03672cd3191f037905bf981eb523a3b71b1 - https://git.kernel.org/stable/c/04bf4f2a497e9877c425c5124652e61fb8a1a0aa - https://git.kernel.org/stable/c/8058061ed9d6bc259d1e678607b07d259342c08f
CVE ID: CVE-2025-37871 State: PUBLISHED Published: 2025-05-09T06:43:59.720Z Last Updated: 2025-11-03T19:56:48.360Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nfsd: decrease sc_count directly if fail to queue dl_recall A deadlock warning occurred when invoking nfs4_put_stid following a failed dl_recall queue operation: T1 T2 nfs4_laundromat nfs4_get_client_reaplist nfs4_anylock_blockers __break_lease spin_lock // ctx->flc_lock spin_lock // clp->cl_lock nfs4_lockowner_has_blockers locks_owner_has_blockers spin_lock // flctx->flc_lock nfsd_break_deleg_cb nfsd_break_one_deleg nfs4_put_stid refcount_dec_and_lock spin_lock // clp
in_lock // flctx->flc_lock nfsd_break_deleg_cb nfsd_break_one_deleg nfs4_put_stid refcount_dec_and_lock spin_lock // clp->cl_lock When a file is opened, an nfs4_delegation is allocated with sc_count initialized to 1, and the file_lease holds a reference to the delegation. The file_lease is then associated with the file through kernel_setlease. The disassociation is performed in nfsd4_delegreturn via the following call chain: nfsd4_delegreturn --> destroy_delegation --> destroy_unhashed_deleg --> nfs4_unlock_deleg_lease --> kernel_setlease --> generic_delete_lease The corresponding sc_count reference will be released after this disassociation. Since nfsd_break_one_deleg executes while holding
ponding sc_count reference will be released after this disassociation. Since nfsd_break_one_deleg executes while holding the flc_lock, the disassociation process becomes blocked when attempting to acquire flc_lock in generic_delete_lease. This means: 1) sc_count in nfsd_break_one_deleg will not be decremented to 0; 2) The nfs4_put_stid called by nfsd_break_one_deleg will not attempt to acquire cl_lock; 3) Consequently, no deadlock condition is created. Given that sc_count in nfsd_break_one_deleg remains non-zero, we can safely perform refcount_dec on sc_count directly. This approach effectively avoids triggering deadlock warnings. Additional Analyst Notes: - CVE Program Container: References
approach effectively avoids triggering deadlock warnings. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b9bbe8f9d5663311d06667ce36d6ed255ead1a26 - https://git.kernel.org/stable/c/a70832d3555987035fc430ccd703acd89393eadb - https://git.kernel.org/stable/c/ba903539fff745d592d893c71b30e5e268a95413 - https://git.kernel.org/stable/c/7d192e27a431026c58d60edf66dc6cd98d0c01fc - https://git.kernel.org/stable/c/a7fce086f6ca84db409b9d58493ea77c1978897c - https://git.kernel.org/stable/c/14985d66b9b99c12995dd99d1c6c8dec4114c2a5 - https://git.kernel.org/stable/c/a1d14d931bf700c1025db8c46d6731aa5cf440f9
CVE ID: CVE-2025-37872 State: PUBLISHED Published: 2025-05-09T06:44:00.570Z Last Updated: 2025-05-26T05:22:44.938Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix memory leak in txgbe_probe() error path When txgbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in txgbe_probe() function, the subsequent error paths after txgbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when txgbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_tabl
ution jumps when txgbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init(). References: - https://git.kernel.org/stable/c/635863d93deb8e352d63a8eba852efeaf1ac3539 - https://git.kernel.org/stable/c/837197a722919f5b0eeb967fe7cb0cc1e83173b9 - https://git.kernel.org/stable/c/b2727326d0a53709380aa147018085d71a6d4843
CVE ID: CVE-2025-37873 State: PUBLISHED Published: 2025-05-09T06:44:01.394Z Last Updated: 2025-05-26T05:22:46.220Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: fix missing ring index trim on error path Commit under Fixes converted tx_prod to be free running but missed masking it on the Tx error path. This crashes on error conditions, for example when DMA mapping fails. References: - https://git.kernel.org/stable/c/21e70f694bc0dcb40174b0940cc52a7769fc19e0 - https://git.kernel.org/stable/c/3742c55de00266fa7c8fd2c5d61a453d223a9cd1 - https://git.kernel.org/stable/c/12f2d033fae957d84c2c0ce604d2a077e61fa2c0
CVE ID: CVE-2025-37874 State: PUBLISHED Published: 2025-05-09T06:44:02.314Z Last Updated: 2025-05-26T05:22:47.495Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ngbe: fix memory leak in ngbe_probe() error path When ngbe_sw_init() is called, memory is allocated for wx->rss_key in wx_init_rss_key(). However, in ngbe_probe() function, the subsequent error paths after ngbe_sw_init() don't free the rss_key. Fix that by freeing it in error path along with wx->mac_table. Also change the label to which execution jumps when ngbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allo
jumps when ngbe_sw_init() fails, because otherwise, it could lead to a double free for rss_key, when the mac_table allocation fails in wx_sw_init(). References: - https://git.kernel.org/stable/c/7c2b66a31c7a4866400f7e6fb43cb32021bfca01 - https://git.kernel.org/stable/c/8335a3feb9d0d97e5e8f76d38b6bb8573d5b4a29 - https://git.kernel.org/stable/c/397487338eff1891c4654ce7deaafbf72a1688b2 - https://git.kernel.org/stable/c/88fa80021b77732bc98f73fb69d69c7cc37b9f0d
CVE ID: CVE-2025-37875 State: PUBLISHED Published: 2025-05-09T06:44:03.368Z Last Updated: 2025-11-03T19:56:49.727Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: igc: fix PTM cycle trigger logic Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction. The issue can be reproduced with the following: $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue. PHC2SYS exits with: "ioctl PTP_OFFSET_PRECISE: Connection time
large, but provides a way to quickly reproduce the issue. PHC2SYS exits with: "ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction fails This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM. The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle. When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel,
quently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump. With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c1f174edaccc5a00f8e218c42a0aa9156efd5f76 - https://git.kernel.org/stable/c/0c03e4fbe1321697d9d04587e21e416705e1b19f - https://git.kern
00f8e218c42a0aa9156efd5f76 - https://git.kernel.org/stable/c/0c03e4fbe1321697d9d04587e21e416705e1b19f - https://git.kernel.org/stable/c/16194ca3f3b4448a062650c869a7b3b206c6f5d3 - https://git.kernel.org/stable/c/f3516229cd12dcd45f23ed01adab17e8772b1bd5 - https://git.kernel.org/stable/c/31959e06143692f7e02b8eef7d7d6ac645637906 - https://git.kernel.org/stable/c/8e404ad95d2c10c261e2ef6992c7c12dde03df0e
CVE ID: CVE-2025-37876 State: PUBLISHED Published: 2025-05-09T06:45:40.934Z Last Updated: 2025-05-26T05:22:50.030Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfs: Only create /proc/fs/netfs with CONFIG_PROC_FS When testing a special config: CONFIG_NETFS_SUPPORTS=y CONFIG_PROC_FS=n The system crashes with something like: [ 3.766197] ------------[ cut here ]------------ [ 3.766484] kernel BUG at mm/mempool.c:560! [ 3.766789] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 3.767123] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W [ 3.767777] Tainted: [W]=WARN [ 3.767968] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), [
wapper/0 Tainted: G W [ 3.767777] Tainted: [W]=WARN [ 3.767968] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), [ 3.768523] RIP: 0010:mempool_alloc_slab.cold+0x17/0x19 [ 3.768847] Code: 50 fe ff 58 5b 5d 41 5c 41 5d 41 5e 41 5f e9 93 95 13 00 [ 3.769977] RSP: 0018:ffffc90000013998 EFLAGS: 00010286 [ 3.770315] RAX: 000000000000002f RBX: ffff888100ba8640 RCX: 0000000000000000 [ 3.770749] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 00000000ffffffff [ 3.771217] RBP: 0000000000092880 R08: 0000000000000000 R09: ffffc90000013828 [ 3.771664] R10: 0000000000000001 R11: 00000000ffffffea R12: 0000000000092cc0 [ 3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40 [ 3.
0000000ffffffea R12: 0000000000092cc0 [ 3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40 [ 3.772554] FS: 0000000000000000(0000) GS:ffff8881b5f3c000(0000) knlGS:0000000000000000 [ 3.773061] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.773443] CR2: ffffffff830901b4 CR3: 0000000004296001 CR4: 0000000000770ef0 [ 3.773884] PKRU: 55555554 [ 3.774058] Call Trace: [ 3.774232] <TASK> [ 3.774371] mempool_alloc_noprof+0x6a/0x190 [ 3.774649] ? _printk+0x57/0x80 [ 3.774862] netfs_alloc_request+0x85/0x2ce [ 3.775147] netfs_readahead+0x28/0x170 [ 3.775395] read_pages+0x6c/0x350 [ 3.775623] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.775928] page_cache_ra_unbounded+0x1bd/0x2
5] read_pages+0x6c/0x350 [ 3.775623] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.775928] page_cache_ra_unbounded+0x1bd/0x2a0 [ 3.776247] filemap_get_pages+0x139/0x970 [ 3.776510] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.776820] filemap_read+0xf9/0x580 [ 3.777054] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.777368] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.777674] ? find_held_lock+0x32/0x90 [ 3.777929] ? netfs_start_io_read+0x19/0x70 [ 3.778221] ? netfs_start_io_read+0x19/0x70 [ 3.778489] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.778800] ? lock_acquired+0x1e6/0x450 [ 3.779054] ? srso_alias_return_thunk+0x5/0xfbef5 [ 3.779379] netfs_buffered_read_iter+0x57/0x80 [ 3.779670] __kernel_read+0x158/0x2
? srso_alias_return_thunk+0x5/0xfbef5 [ 3.779379] netfs_buffered_read_iter+0x57/0x80 [ 3.779670] __kernel_read+0x158/0x2c0 [ 3.779927] bprm_execve+0x300/0x7a0 [ 3.780185] kernel_execve+0x10c/0x140 [ 3.780423] ? __pfx_kernel_init+0x10/0x10 [ 3.780690] kernel_init+0xd5/0x150 [ 3.780910] ret_from_fork+0x2d/0x50 [ 3.781156] ? __pfx_kernel_init+0x10/0x10 [ 3.781414] ret_from_fork_asm+0x1a/0x30 [ 3.781677] </TASK> [ 3.781823] Modules linked in: [ 3.782065] ---[ end trace 0000000000000000 ]--- This is caused by the following error path in netfs_init(): if (!proc_mkdir("fs/netfs", NULL)) goto error_proc; Fix this by adding ifdef in netfs_main(), so that /proc/fs/netfs is only created with CONFIG_PRO
NULL)) goto error_proc; Fix this by adding ifdef in netfs_main(), so that /proc/fs/netfs is only created with CONFIG_PROC_FS. References: - https://git.kernel.org/stable/c/2ef6eea2efce01d1956ace483216f6b6e26330c9 - https://git.kernel.org/stable/c/6c4c5e0b96a90f2a11c378e66edc1f25165e10b6 - https://git.kernel.org/stable/c/40cb48eba3b4b79e110c1a35d33a48cac54507a2
CVE ID: CVE-2025-37877 State: PUBLISHED Published: 2025-05-09T06:45:41.751Z Last Updated: 2025-05-26T05:22:51.302Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu: Clear iommu-dma ops on cleanup If iommu_device_register() encounters an error, it can end up tearing down already-configured groups and default domains, however this currently still leaves devices hooked up to iommu-dma (and even historically the behaviour in this area was at best inconsistent across architectures/drivers...) Although in the case that an IOMMU is present whose driver has failed to probe, users cannot necessarily expect DMA to work anyway, it's s
se that an IOMMU is present whose driver has failed to probe, users cannot necessarily expect DMA to work anyway, it's still arguable that we should do our best to put things back as if the IOMMU driver was never there at all, and certainly the potential for crashing in iommu-dma itself is undesirable. Make sure we clean up the dev->dma_iommu flag along with everything else. References: - https://git.kernel.org/stable/c/b14d98641312d972bb3f38e82eddf92898522389 - https://git.kernel.org/stable/c/104a84276821aed0ed241ce0d82d6c3267e3fcb8 - https://git.kernel.org/stable/c/280e5a30100578106a4305ce0118e0aa9b866f12
CVE ID: CVE-2025-37878 State: PUBLISHED Published: 2025-05-09T06:45:42.459Z Last Updated: 2025-05-26T05:22:52.562Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix WARN_ON(!ctx) in __free_event() for partial init Move the get_ctx(child_ctx) call and the child_event->ctx assignment to occur immediately after the child event is allocated. Ensure that child_event->ctx is non-NULL before any subsequent error path within inherit_event calls free_event(), satisfying the assumptions of the cleanup code. Details: There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to
Details: There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression. The code initially incremented refcount then assigned context immediately after the child_event was created. Later, an early validity check for child_event was added before the refcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was added, assuming event->ctx is valid if the pmu_ctx is valid. The problem is that the WARN_ON_ONCE() could trigger after the initial check passed but before child_event->ctx was assigned, violating its precondition. The solution is to assign child_event->ctx right after its initial validation. T
s assigned, violating its precondition. The solution is to assign child_event->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARN_ON_ONCE(). To resolve it, defer the refcount update and child_event->ctx assignment directly after child_event->pmu_ctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmu_ctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in child_ctx to find_get_pmu_context before its refcount/assignment. [ mingo: Expanded the changelog from another email by Gabriel Shahrouz
d_get_pmu_context before its refcount/assignment. [ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ] References: - https://git.kernel.org/stable/c/1fe9b92eede32574dbe05b5bdb6ad666b350bed0 - https://git.kernel.org/stable/c/90dc6c1e3b200812da8d0aa030e1b7fda8226d0e - https://git.kernel.org/stable/c/cb56cd11feabf99e08bc18960700a53322ffcea7 - https://git.kernel.org/stable/c/0ba3a4ab76fd3367b9cb680cad70182c896c795c
CVE ID: CVE-2025-37879 State: PUBLISHED Published: 2025-05-09T06:45:43.197Z Last Updated: 2025-11-03T19:56:51.125Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: 9p/net: fix improper handling of bogus negative read/write replies In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed. Make variables unsigned to avoid this problem. The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295
linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3) Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/468ff4a7c61fb811c596a7c44b6a5455e40fd12b - https://git.kernel.org/stable/c/a68768e280b7d0c967ea509e791bb9b90adc94a5 - https://git.kernel.org/stable/c/c548f95688e2b5ae0e2ae43d53cf717156c7d034 - https://git.kernel.org/stable/c/374e4cd75617c8c2552f562f39dd989583f5c330 - https://git.kernel.org/stable/c/d0259a856afca31d699b706ed5e2adf11086c73b
CVE ID: CVE-2025-37880 State: PUBLISHED Published: 2025-05-09T06:45:44.117Z Last Updated: 2025-05-26T05:22:55.166Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: um: work around sched_yield not yielding in time-travel mode sched_yield by a userspace may not actually cause scheduling in time-travel mode as no time has passed. In the case seen it appears to be a badly implemented userspace spinlock in ASAN. Unfortunately, with time-travel it causes an extreme slowdown or even deadlock depending on the kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS). Work around it by accounting time to the process whenever it executes
figuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS). Work around it by accounting time to the process whenever it executes a sched_yield syscall. References: - https://git.kernel.org/stable/c/990ddc65173776f1e01e7135d8c1fd5f8fd4d5d2 - https://git.kernel.org/stable/c/887c5c12e80c8424bd471122d2e8b6b462e12874
CVE ID: CVE-2025-37881 State: PUBLISHED Published: 2025-05-09T06:45:45.205Z Last Updated: 2025-11-03T19:56:53.885Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() The variable d->name, returned by devm_kasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c"). This issue is found by our static analysis tool Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a777ccfb
analysis tool Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a777ccfb9ba8d43f745e41b69ba39d4a506a081e - https://git.kernel.org/stable/c/c8d4faf452a627f9b09c3a5c366133a19e5b7a28 - https://git.kernel.org/stable/c/d26a6093d52904cacdbb75424c323c19b443a890 - https://git.kernel.org/stable/c/36d68151712e525450f0fbb3045e7110f0d9b610 - https://git.kernel.org/stable/c/cfa7984f69359761b07a7831c1258c0fde1e0389 - https://git.kernel.org/stable/c/052fb65335befeae8500e88d69ea022266baaf6d - https://git.kernel.org/stable/c/61006ca381b4d65d2b8ca695ea8da1ce18d6dee3 - https://git.kernel.org/stable/c/8c75f3e6a433d92084ad4e78b029ae680865420f
CVE ID: CVE-2025-37882 State: PUBLISHED Published: 2025-05-09T06:45:45.936Z Last Updated: 2025-05-26T05:22:57.713Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix isochronous Ring Underrun/Overrun event handling The TRB pointer of these events points at enqueue at the time of error occurrence on xHCI 1.1+ HCs or it's NULL on older ones. By the time we are handling the event, a new TD may be queued at this ring position. I can trigger this race by rising interrupt moderation to increase IRQ handling delay. Similar delay may occur naturally due to system load. If this ever happens after a Missed Service Error, misse
ng delay. Similar delay may occur naturally due to system load. If this ever happens after a Missed Service Error, missed TDs will be skipped and the new TD processed as if it matched the event. It could be given back prematurely, risking data loss or buffer UAF by the xHC. Don't complete TDs on xrun events and don't warn if queued TDs don't match the event's TRB pointer, which can be NULL or a link/no-op TRB. Don't warn if there are no queued TDs at all. Now that it's safe, also handle xrun events if the skip flag is clear. This ensures completion of any TD stuck in 'error mid TD' state right before the xrun event, which could happen if a driver submits a finite number of URBs to a buggy HC
mid TD' state right before the xrun event, which could happen if a driver submits a finite number of URBs to a buggy HC and then an error occurs on the last TD. References: - https://git.kernel.org/stable/c/16a7a8e6c47fea5c847beb696c8c21a7a44c1915 - https://git.kernel.org/stable/c/39a080a2925c81b0f1da0add44722ef2b78e5454 - https://git.kernel.org/stable/c/906dec15b9b321b546fd31a3c99ffc13724c7af4
CVE ID: CVE-2025-37883 State: PUBLISHED Published: 2025-05-09T06:45:46.716Z Last Updated: 2025-11-03T19:56:55.267Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Add check for get_zeroed_page() Add check for the return value of get_zeroed_page() in sclp_console_init() to prevent null pointer dereference. Furthermore, to solve the memory leak caused by the loop allocation, add a free helper to do the free job. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e1e00dc45648125ef7cb87ebc3b581ac224e7b39 - https://git.kernel.org/stable/c/397254706eba9d8f99fd237feede7ab3169a7f9