Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-39705 State: PUBLISHED Published: 2025-09-05T17:21:11.767Z Last Updated: 2025-09-29T05:57:47.898Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a Null pointer dereference vulnerability [Why] A null pointer dereference vulnerability exists in the AMD display driver's (DC module) cleanup function dc_destruct(). When display control context (dc->ctx) construction fails (due to memory allocation failure), this pointer remains NULL. During subsequent error handling when dc_destruct() is called, there's no NULL check before dereferencing the perf_trace member (dc->ctx->perf_trace), causing a ker
truct() is called, there's no NULL check before dereferencing the perf_trace member (dc->ctx->perf_trace), causing a kernel null pointer dereference crash. [How] Check if dc->ctx is non-NULL before dereferencing. (Updated commit text and removed unnecessary error message) (cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404) References: - https://git.kernel.org/stable/c/0961673cc5f0055957aa46f25eb4ef6c07e00165 - https://git.kernel.org/stable/c/4ade995b9b25b3c6e8dc42c27070340f1358d8c8 - https://git.kernel.org/stable/c/1bcf63a44381691d6192872801f830ce3250e367
CVE ID: CVE-2025-39706 State: PUBLISHED Published: 2025-09-05T17:21:12.841Z Last Updated: 2025-11-03T17:42:33.582Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Destroy KFD debugfs after destroy KFD wq Since KFD proc content was moved to kernel debugfs, we can't destroy KFD debugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq prior to kfd_debugfs_fini to fix a kernel NULL pointer problem. It happens when /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini but kfd_process_destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry); tries to remove /sy
destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry); tries to remove /sys/kernel/debug/kfd/proc/<pid> while /sys/kernel/debug/kfd is already gone. It hangs the kernel by kernel NULL pointer. (cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233) Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/fc35c955da799ba62f6f977d58e0866d0251e3f8 - https://git.kernel.org/stable/c/74ee7445c3b61c3bd899a54bd82c1982cb3a8206 - https://git.kernel.org/stable/c/96609a51e6134542bf90e053c2cd2fe4f61ebce3 - https://git.kernel.org/stable/c/910735ded17cc306625e7e1cdcc8102f7ac60994 - https://git.kernel.org/stab
2cd2fe4f61ebce3 - https://git.kernel.org/stable/c/910735ded17cc306625e7e1cdcc8102f7ac60994 - https://git.kernel.org/stable/c/2e58401a24e7b2d4ec619104e1a76590c1284a4c
CVE ID: CVE-2025-39707 State: PUBLISHED Published: 2025-09-05T17:21:13.958Z Last Updated: 2025-09-29T05:57:50.405Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities HUBBUB structure is not initialized on DCE hardware, so check if it is NULL to avoid null dereference while accessing amdgpu_dm_capabilities file in debugfs. References: - https://git.kernel.org/stable/c/83cfdc2b018cd9c0f927b781d4e07c0d4a911fac - https://git.kernel.org/stable/c/98e92fceb9507901e3e8b550e93b843306abd354 - https://git.kernel.org/stable/c/b4a69f7f29c8a459ad6b4d8a8b72450f1d9fd288
CVE ID: CVE-2025-39708 State: PUBLISHED Published: 2025-09-05T17:21:15.082Z Last Updated: 2025-09-29T05:57:51.657Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: iris: Fix NULL pointer dereference A warning reported by smatch indicated a possible null pointer dereference where one of the arguments to API "iris_hfi_gen2_handle_system_error" could sometimes be null. To fix this, add a check to validate that the argument passed is not null before accessing its members. References: - https://git.kernel.org/stable/c/992ddee3c0da5f113ba86892ace467c1ac645538 - https://git.kernel.org/stable/c/0f837559ccdd275c5a059e6ac4d5034b0340
stable/c/992ddee3c0da5f113ba86892ace467c1ac645538 - https://git.kernel.org/stable/c/0f837559ccdd275c5a059e6ac4d5034b03409f1d
CVE ID: CVE-2025-39709 State: PUBLISHED Published: 2025-09-05T17:21:16.153Z Last Updated: 2025-11-03T17:42:35.451Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: venus: protect against spurious interrupts during probe Make sure the interrupt handler is initialized before the interrupt is registered. If the IRQ is registered before hfi_create(), it's possible that an interrupt fires before the handler setup is complete, leading to a NULL dereference. This error condition has been observed during system boot on Rb3Gen2. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/18c2b2b
oot on Rb3Gen2. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/18c2b2bd982b8546312c9a7895515672169f28e0 - https://git.kernel.org/stable/c/88cf63c2599761c48dec8f618d57dccf8f6f4b53 - https://git.kernel.org/stable/c/9db6a78bc5e418e0064e2248c8f3b9b9e8418646 - https://git.kernel.org/stable/c/37cc0ac889b018097c217c5929fd6dc2aed636a1 - https://git.kernel.org/stable/c/f54be97bc69b1096198b6717c150dec69f2a1b4d - https://git.kernel.org/stable/c/639eb587f977c02423f4762467055b23902b4131 - https://git.kernel.org/stable/c/e796028b4835af00d9a38ebbb208ec3a6634702a - https://git.kernel.org/stable/c/3200144a2fa4209dc084a19941b9b203b43580f0
CVE ID: CVE-2025-39710 State: PUBLISHED Published: 2025-09-05T17:21:17.243Z Last Updated: 2025-11-03T17:42:37.345Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: venus: Add a check for packet size after reading from shared memory Add a check to ensure that the packet size does not exceed the number of available words after reading the packet header from shared memory. This ensures that the size provided by the firmware is safe to process and prevent potential out-of-bounds memory access. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0520c89f6280d2b60ab537d5743601185ee7d8
yst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0520c89f6280d2b60ab537d5743601185ee7d8ab - https://git.kernel.org/stable/c/f5b7a943055a4a106d40a03bacd940e28cc1955f - https://git.kernel.org/stable/c/ef09b96665f16f3f0bac4e111160e6f24f1f8791 - https://git.kernel.org/stable/c/7638bae4539dcebc3f68fda74ac35d73618ec440 - https://git.kernel.org/stable/c/ba567c2e52fbcf0e20502746bdaa79e911c2e8cf - https://git.kernel.org/stable/c/2d8cea8310a245730816a1fd0c9fa4a5a3bdc68c - https://git.kernel.org/stable/c/f0cbd9386f974d310a0d20a02e4a1323e95ea654 - https://git.kernel.org/stable/c/49befc830daa743e051a65468c05c2ff9e8580e6
CVE ID: CVE-2025-39711 State: PUBLISHED Published: 2025-09-05T17:21:18.348Z Last Updated: 2025-09-29T05:57:55.383Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls Both the ACE and CSI driver are missing a mei_cldev_disable() call in their remove() function. This causes the mei_cl client to stay part of the mei_device->file_list list even though its memory is freed by mei_cl_bus_dev_release() calling kfree(cldev->cl). This leads to a use-after-free when mei_vsc_remove() runs mei_stop() which first removes all mei bus devices calling mei_ace_remove() and m
-after-free when mei_vsc_remove() runs mei_stop() which first removes all mei bus devices calling mei_ace_remove() and mei_csi_remove() followed by mei_cl_bus_dev_release() and then calls mei_cl_all_disconnect() which walks over mei_device->file_list dereferecing the just freed cldev->cl. And mei_vsc_remove() it self is run at shutdown because of the platform_device_unregister(tp->pdev) in vsc_tp_shutdown() When building a kernel with KASAN this leads to the following KASAN report: [ 106.634504] ================================================================== [ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of s
] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1 [ 106.634729] [ 106.634767] Tainted: [E]=UNSIGNED_MODULE [ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025 [ 106.634773] Call Trace: [ 106.634777] <TASK> ... [ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) [ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei [ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] mei_stop (drivers/m
5 (discriminator 4)) mei [ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei [ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc [ 106.635066] platform_remove (drivers/base/platform.c:1424) Add the missing mei_cldev_disable() calls so that the mei_cl gets removed from mei_device->file_list before it is freed to fix this. References: - https://git.kernel.org/stable/c/3c0e4cc4f55f9a1db2a761e4ffb27c9594245888 - https://git.kernel.org/stable/c/639f5b33fcd7c59157f29b09f6f2866eacf9279c - https://git.kernel.org/stable/c/1dfe73394dcfc9b049c8da0dc181c45f156a5f49 - https://git.kerne
157f29b09f6f2866eacf9279c - https://git.kernel.org/stable/c/1dfe73394dcfc9b049c8da0dc181c45f156a5f49 - https://git.kernel.org/stable/c/0c92c49fc688cfadacc47ae99b06a31237702e9e
CVE ID: CVE-2025-39712 State: PUBLISHED Published: 2025-09-05T17:21:19.494Z Last Updated: 2025-09-29T05:57:56.603Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval Getting / Setting the frame interval using the V4L2 subdev pad ops get_frame_interval/set_frame_interval causes a deadlock, as the subdev state is locked in the [1] but also in the driver itself. In [2] it's described that the caller is responsible to acquire and release the lock in this case. Therefore, acquiring the lock in the driver is wrong. Remove the lock acquisitions/releases from mt9m114_ifp
this case. Therefore, acquiring the lock in the driver is wrong. Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval() and mt9m114_ifp_set_frame_interval(). [1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129 [2] Documentation/driver-api/media/v4l2-subdev.rst References: - https://git.kernel.org/stable/c/0d23b548d71e5d76955fdf1d73addd8f6494f602 - https://git.kernel.org/stable/c/41b97490a1656bdc7038d6345a84b08d45deafc6 - https://git.kernel.org/stable/c/298d1471cf83d5a2a05970e41822a2403f451086
CVE ID: CVE-2025-39713 State: PUBLISHED Published: 2025-09-05T17:21:20.459Z Last Updated: 2025-11-03T17:42:39.229Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt() In the interrupt handler rain_interrupt(), the buffer full check on rain->buf_len is performed before acquiring rain->buf_lock. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as rain->buf_len is concurrently accessed and modified in the work handler rain_irq_work_handler() under the same lock. Multiple interrupt invocations can race, with each reading buf_len before it becomes fu
k_handler() under the same lock. Multiple interrupt invocations can race, with each reading buf_len before it becomes full and then proceeding. This can lead to both interrupts attempting to write to the buffer, incrementing buf_len beyond its capacity (DATA_SIZE) and causing a buffer overflow. Fix this bug by moving the spin_lock() to before the buffer full check. This ensures that the check and the subsequent buffer modification are performed atomically, preventing the race condition. An corresponding spin_unlock() is added to the overflow path to correctly release the lock. This possible bug was found by an experimental static analysis tool developed by our team. Additional Analyst Notes:
ck. This possible bug was found by an experimental static analysis tool developed by our team. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2964dbe631fd21ad7873b1752b895548d3c12496 - https://git.kernel.org/stable/c/6aaef1a75985865d8c6c5b65fb54152060faba48 - https://git.kernel.org/stable/c/fbc81e78d75bf28972bc22b1599559557b1a1b83 - https://git.kernel.org/stable/c/3c3e33b7edca7a2d6a96801f287f9faeb684d655 - https://git.kernel.org/stable/c/1c2769dc80255824542ea5a4ff1a07dcdeb1603f - https://git.kernel.org/stable/c/ed905fe7cba03cf22ae0b84cf1b73cd1c070423a - https://git.kernel.org/stable/c/ff9dd3db6cd4c6b54a2ecbc58151bea4ec63bc59 - https://git.ker
cf22ae0b84cf1b73cd1c070423a - https://git.kernel.org/stable/c/ff9dd3db6cd4c6b54a2ecbc58151bea4ec63bc59 - https://git.kernel.org/stable/c/7af160aea26c7dc9e6734d19306128cce156ec40
CVE ID: CVE-2025-39714 State: PUBLISHED Published: 2025-09-05T17:21:21.435Z Last Updated: 2025-11-03T17:42:41.101Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: usbtv: Lock resolution while streaming When an program is streaming (ffplay) and another program (qv4l2) changes the TV standard from NTSC to PAL, the kernel crashes due to trying to copy to unmapped memory. Changing from NTSC to PAL increases the resolution in the usbtv struct, but the video plane buffer isn't adjusted, so it overflows. [hverkuil: call vb2_is_busy instead of vb2_is_streaming] Additional Analyst Notes: - CVE Program Container: References: - http
uil: call vb2_is_busy instead of vb2_is_streaming] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c35e7c7a004ef379a1ae7c7486d4829419acad1d - https://git.kernel.org/stable/c/ee7bade8b9244834229b12b6e1e724939bedd484 - https://git.kernel.org/stable/c/5427dda195d6baf23028196fd55a0c90f66ffa61 - https://git.kernel.org/stable/c/ef9b3c22405192afaa279077ddd45a51db90b83d - https://git.kernel.org/stable/c/3d83d0b5ae5045a7a246ed116b5f6c688a12f9e9 - https://git.kernel.org/stable/c/c3d75524e10021aa5c223d94da4996640aed46c0 - https://git.kernel.org/stable/c/9f886d21e235c4bd038cb20f6696084304197ab3 - https://git.kernel.org/stable/c/7e40e0bb778907b2441bff68d73
rnel.org/stable/c/9f886d21e235c4bd038cb20f6696084304197ab3 - https://git.kernel.org/stable/c/7e40e0bb778907b2441bff68d73c3eb6b6cd319f
CVE ID: CVE-2025-39715 State: PUBLISHED Published: 2025-09-05T17:21:22.330Z Last Updated: 2025-11-03T17:42:42.036Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: parisc: Revise gateway LWS calls to probe user read access We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS com
o this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER). Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e8b496c52aa0c6572d88db7cab85aeea6f9c194d - https://git.kernel.org/stable/c/8bccf47adbf658293528e86960e6d6f736b1c9f7 - https://git.kernel.org/stable/c/bc0a24c24ceebabb5ba65900e332233d79e625e6 - https://git.kernel.org/stable/c/9b6af875baba9c4679b55f4561e201485451305f - https://
c24ceebabb5ba65900e332233d79e625e6 - https://git.kernel.org/stable/c/9b6af875baba9c4679b55f4561e201485451305f - https://git.kernel.org/stable/c/f6334f4ae9a4e962ba74b026e1d965dfdf8cbef8
CVE ID: CVE-2025-39716 State: PUBLISHED Published: 2025-09-05T17:21:23.429Z Last Updated: 2025-11-03T17:42:43.013Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: parisc: Revise __get_user() to probe user read access Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call. Fix this by probing read access rights at privilege level 3 (PRIV_USER) and sett
ad protected address via a system call. Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed. Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/28a9b71671fb4a2993ef85b8ef6f117ea63894fe - https://git.kernel.org/stable/c/4c981077255acc2ed5b3df6e8dd0125c81b626a9 - https://git.kernel.org/stable/c/f410ef9a032caf98117256b22139c31342d7bb06 - https://git.kernel.org/stable/c/741b163e440683195b8fd4fc8495fcd0105c6ab7 - https://git.kernel.org/stable/c/89f686a0fb6e473a876a9a60a13aec67a
rg/stable/c/741b163e440683195b8fd4fc8495fcd0105c6ab7 - https://git.kernel.org/stable/c/89f686a0fb6e473a876a9a60a13aec67a62b9a7e
CVE ID: CVE-2025-39717 State: PUBLISHED Published: 2025-09-05T17:21:24.528Z Last Updated: 2025-09-29T05:58:02.957Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: open_tree_attr: do not allow id-mapping changes without OPEN_TREE_CLONE As described in commit 7a54947e727b ('Merge patch series "fs: allow changing idmappings"'), open_tree_attr(2) was necessary in order to allow for a detached mount to be created and have its idmappings changed without the risk of any racing threads operating on it. For this reason, mount_setattr(2) still does not allow for id-mappings to be changed. However, there was a bug in commit 2462651ffa76 ("
mount_setattr(2) still does not allow for id-mappings to be changed. However, there was a bug in commit 2462651ffa76 ("fs: allow changing idmappings") which allowed users to bypass this restriction by calling open_tree_attr(2) *without* OPEN_TREE_CLONE. can_idmap_mount() prevented this bug from allowing an attached mountpoint's id-mapping from being modified (thanks to an is_anon_ns() check), but this still allows for detached (but visible) mounts to have their be id-mapping changed. This risks the same UAF and locking issues as described in the merge commit, and was likely unintentional. References: - https://git.kernel.org/stable/c/69dbdc711d9130136824e3830191a6afffa0a1f0 - https://git.ke
y unintentional. References: - https://git.kernel.org/stable/c/69dbdc711d9130136824e3830191a6afffa0a1f0 - https://git.kernel.org/stable/c/9308366f062129d52e0ee3f7a019f7dd41db33df
CVE ID: CVE-2025-39718 State: PUBLISHED Published: 2025-09-05T17:21:25.959Z Last Updated: 2025-11-03T17:42:44.024Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Validate length in packet header before skb_put() When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately, virtio_vsock_skb_rx_put() uses the length from the packet header as the length argument to skb_put(), potentially resulting in SKB overflow if the host has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put(). Addit
t has gone wonky. Validate the length as advertised by the packet header before calling virtio_vsock_skb_rx_put(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/969b06bd8b7560efb100a34227619e7d318fbe05 - https://git.kernel.org/stable/c/ee438c492b2e0705d819ac0e25d04fae758d8f8f - https://git.kernel.org/stable/c/faf332a10372390ce65d0b803888f4b25a388335 - https://git.kernel.org/stable/c/676f03760ca1d69c2470cef36c44dc152494b47c - https://git.kernel.org/stable/c/0dab92484474587b82e8e0455839eaf5ac7bf894
CVE ID: CVE-2025-39719 State: PUBLISHED Published: 2025-09-05T17:21:26.952Z Last Updated: 2025-11-03T17:42:44.953Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: imu: bno055: fix OOB access of hw_xlate array Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c. In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which
esult in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array. By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a0691ab6334f1769acc64ea9e319414a682ff45d - https://git.kernel.org/stable/c/50e823a23816b792daf6e8405f8d6045952bb90e - https://git.kernel.org/stable/c/4808ca3aa30ae857454d0b41d2d0bf161a312b45 - https://git.kernel.org/stable/c/5c2b601922c064f7be70ae8621277f18d1ffec59 - https://git.
0ae857454d0b41d2d0bf161a312b45 - https://git.kernel.org/stable/c/5c2b601922c064f7be70ae8621277f18d1ffec59 - https://git.kernel.org/stable/c/399b883ec828e436f1a721bf8551b4da8727e65b
CVE ID: CVE-2025-39720 State: PUBLISHED Published: 2025-09-05T17:21:28.060Z Last Updated: 2025-09-29T05:58:06.752Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix refcount leak causing resource not released When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released. References: - https://git.kernel.org/stable/c/a1d2bab4d53368a526c97aba92671dd71814f95a - https://git.kernel.org/stable/c/36e010bb865fbaa1202fe9bcce3fd486d6db7606 - https://git.kernel.org/stable/c/9a7abce6e8c0e2145b346a6
t.kernel.org/stable/c/36e010bb865fbaa1202fe9bcce3fd486d6db7606 - https://git.kernel.org/stable/c/9a7abce6e8c0e2145b346a6d4abf0d9655e9b0e8 - https://git.kernel.org/stable/c/89bb430f621124af39bb31763c4a8b504c9651e2
CVE ID: CVE-2025-39721 State: PUBLISHED Published: 2025-09-05T17:21:28.911Z Last Updated: 2025-09-29T05:58:07.985Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: qat - flush misc workqueue during device shutdown Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded. Since the driver uses a shared workqueue (`qat_misc_wq`) across all device