Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
or the wait_queue_head has been freed. We need to check there are no tasks queued on any of the subdevices' wait queues before allowing the device to be detached by the `COMEDI_DEVCONFIG` ioctl. Tasks will read-lock `dev->attach_lock` before adding themselves to the subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl handler by write-locking `dev->attach_lock` before checking that all of the subdevices are safe to be deleted. This includes testing for any sleepers on the subdevices' wait queues. It remains locked until the device has been detached. This requires the `comedi_device_detach()` function to be refactored slightly, moving the bulk of it into new function `come
requires the `comedi_device_detach()` function to be refactored slightly, moving the bulk of it into new function `comedi_device_detach_locked()`. Note that the refactor of `comedi_device_detach()` results in `comedi_device_cancel_all()` now being called while `dev->attach_lock` is write-locked, which wasn't the case previously, but that does not matter. Thanks to Jens Axboe for diagnosing the problem and co-developing this patch. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/fe67122ba781df44a1a9716eb1dfd751321ab512 - https://git.kernel.org/stable/c/cd4286123d6948ff638ea9cd5818ae4796d5d252 - https://git.kernel.org/stable/c/d85fac8729c9acfd7
s://git.kernel.org/stable/c/cd4286123d6948ff638ea9cd5818ae4796d5d252 - https://git.kernel.org/stable/c/d85fac8729c9acfd72368faff1d576ec585e5c8f - https://git.kernel.org/stable/c/0f989f9d05492028afd2bded4b42023c57d8a76e - https://git.kernel.org/stable/c/5c4a2ffcbd052c69bbf4680677d4c4eaa5a252d4 - https://git.kernel.org/stable/c/017198079551a2a5cf61eae966af3c4b145e1f3b - https://git.kernel.org/stable/c/71ca60d2e631cf9c63bcbc7017961c61ff04e419 - https://git.kernel.org/stable/c/5724e82df4f9a4be62908362c97d522d25de75dd - https://git.kernel.org/stable/c/35b6fc51c666fc96355be5cd633ed0fe4ccf68b2
CVE ID: CVE-2025-38688 State: PUBLISHED Published: 2025-09-04T15:32:42.607Z Last Updated: 2025-09-29T05:56:02.884Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommufd: Prevent ALIGN() overflow When allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova. Open code the ALIGN() using get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length earlier either. Consolidate the two copies of this code under a single helper. This bug would allow userspace to create a mapping that overl
olidate the two copies of this code under a single helper. This bug would allow userspace to create a mapping that overlaps with some other mapping or a reserved range. References: - https://git.kernel.org/stable/c/d19b817540c0abe84854a64ee9ee34cecc3bbeef - https://git.kernel.org/stable/c/ebb6021560b94649bec6b8faba6fe0dca2218e81 - https://git.kernel.org/stable/c/e42a046bb41dcdde4f766a17d8211842007ed537 - https://git.kernel.org/stable/c/79fad1917802c28de51a479318a056a6fbe3e2f2 - https://git.kernel.org/stable/c/b42497e3c0e74db061eafad41c0cd7243c46436b
CVE ID: CVE-2025-38689 State: PUBLISHED Published: 2025-09-04T15:32:43.530Z Last Updated: 2025-09-29T05:56:04.310Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Fix NULL dereference in avx512_status() Problem ------- With CONFIG_X86_DEBUG_FPU enabled, reading /proc/[kthread]/arch_status causes a warning and a NULL pointer dereference. This is because the AVX-512 timestamp code uses x86_task_fpu() but doesn't check it for NULL. CONFIG_X86_DEBUG_FPU addles that function for kernel threads (PF_KTHREAD specifically), making it return NULL. The point of the warning was to ensure that kernel threads only access task->fpu af
pecifically), making it return NULL. The point of the warning was to ensure that kernel threads only access task->fpu after going through kernel_fpu_begin()/_end(). Note: all kernel tasks exposed in /proc have a valid task->fpu. Solution -------- One option is to silence the warning and check for NULL from x86_task_fpu(). However, that warning is fairly fresh and seems like a defense against misuse of the FPU state in kernel threads. Instead, stop outputting AVX-512_elapsed_ms for kernel threads altogether. The data was garbage anyway because avx512_timestamp is only updated for user threads, not kernel threads. If anyone ever wants to track kernel thread AVX-512 use, they can come back late
d for user threads, not kernel threads. If anyone ever wants to track kernel thread AVX-512 use, they can come back later and do it properly, separate from this bug fix. [ dhansen: mostly rewrite changelog ] References: - https://git.kernel.org/stable/c/2ca887e81095b99d890a8878841f36f4920181e6 - https://git.kernel.org/stable/c/31cd31c9e17ece125aad27259501a2af69ccb020
CVE ID: CVE-2025-38690 State: PUBLISHED Published: 2025-09-04T15:32:44.559Z Last Updated: 2025-09-29T05:56:05.662Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe/migrate: prevent infinite recursion If the buf + offset is not aligned to XE_CAHELINE_BYTES we fallback to using a bounce buffer. However the bounce buffer here is allocated on the stack, and the only alignment requirement here is that it's naturally aligned to u8, and not XE_CACHELINE_BYTES. If the bounce buffer is also misaligned we then recurse back into the function again, however the new bounce buffer might also not be aligned, and might never be until we e
rse back into the function again, however the new bounce buffer might also not be aligned, and might never be until we eventually blow through the stack, as we keep recursing. Instead of using the stack use kmalloc, which should respect the power-of-two alignment request here. Fixes a kernel panic when triggering this path through eudebug. v2 (Stuart): - Add build bug check for power-of-two restriction - s/EINVAL/ENOMEM/ (cherry picked from commit 38b34e928a08ba594c4bbf7118aa3aadacd62fff) References: - https://git.kernel.org/stable/c/89f511c024879c5812cc0c010a6663b5e49950f3 - https://git.kernel.org/stable/c/9d7a1cbebbb691891671def57407ba2f8ee914e8
CVE ID: CVE-2025-38691 State: PUBLISHED Published: 2025-09-04T15:32:45.301Z Last Updated: 2025-11-03T17:41:16.489Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix uninited ptr deref in block/scsi layout The error occurs on the third attempt to encode extents. When function ext_tree_prepare_commit() reallocates a larger buffer to retry encoding extents, the "layoutupdate_pages" page array is initialized only after the retry loop. But ext_tree_free_commitdata() is called on every iteration and tries to put pages in the array, thus dereferencing uninitialized pointers. An additional problem is that there is no limit on th
put pages in the array, thus dereferencing uninitialized pointers. An additional problem is that there is no limit on the maximum possible buffer_size. When there are too many extents, the client may create a layoutcommit that is larger than the maximum possible RPC size accepted by the server. During testing, we observed two typical scenarios. First, one memory page for extents is enough when we work with small files, append data to the end of the file, or preallocate extents before writing. But when we fill a new large file without preallocating, the number of extents can be huge, and counting the number of written extents in ext_tree_encode_commit() does not help much. Since this number i
be huge, and counting the number of written extents in ext_tree_encode_commit() does not help much. Since this number increases even more between unlocking and locking of ext_tree, the reallocated buffer may not be large enough again and again. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/579b85f893d9885162e1cabf99a4a088916e143e - https://git.kernel.org/stable/c/2896f101110076ac6bf99d7aaf463d61e26f89dd - https://git.kernel.org/stable/c/4f783333cbfa2ee7d4aa8e47f6bd1b3f77534fcf - https://git.kernel.org/stable/c/9be5c04beca3202d0a5f09fb4b2ecb644caa0bc5 - https://git.kernel.org/stable/c/24334f3cf8a294f253071b5bf22d754dbb6d0f2d - https://git.ke
202d0a5f09fb4b2ecb644caa0bc5 - https://git.kernel.org/stable/c/24334f3cf8a294f253071b5bf22d754dbb6d0f2d - https://git.kernel.org/stable/c/f0b2eee3fbba9b7e3746ef698424ef5e4a197776 - https://git.kernel.org/stable/c/94ec6d939031a616474376dadbf4a8d0ef8b0bcc - https://git.kernel.org/stable/c/37c3443a2685528f972d910a6fb87716b96fef46 - https://git.kernel.org/stable/c/9768797c219326699778fba9cd3b607b2f1e7950
CVE ID: CVE-2025-38692 State: PUBLISHED Published: 2025-09-04T15:32:46.004Z Last Updated: 2025-09-29T05:56:08.225Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: exfat: add cluster chain loop check for dir An infinite loop may occur if the following conditions occur due to file system corruption. (1) Condition for exfat_count_dir_entries() to loop infinitely. - The cluster chain includes a loop. - There is no UNUSED entry in the cluster chain. (2) Condition for exfat_create_upcase_table() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and up-case table entry in the clu
The cluster chain of the root directory includes a loop. - There are no UNUSED entry and up-case table entry in the cluster chain of the root directory. (3) Condition for exfat_load_bitmap() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and bitmap entry in the cluster chain of the root directory. (4) Condition for exfat_find_dir_entry() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. (5) Condition for exfat_check_dir_empty() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. - All files a
ely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. - All files and sub-directories under the directory are deleted. This commit adds checks to break the above infinite loop. References: - https://git.kernel.org/stable/c/868f23286c1a13162330fa6c614fe350f78e3f82 - https://git.kernel.org/stable/c/aa8fe7b7b73d4c9a41bb96cb3fb3092f794ecb33 - https://git.kernel.org/stable/c/e2066ca3ef49a30920d8536fa366b2a183a808ee - https://git.kernel.org/stable/c/4c3cda20c4cf1871e27868d08fda06b79bc7d568 - https://git.kernel.org/stable/c/99f9a97dce39ad413c39b92c90393bbd6778f3fd
CVE ID: CVE-2025-38693 State: PUBLISHED Published: 2025-09-04T15:32:46.726Z Last Updated: 2025-11-03T17:41:18.481Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serpar In w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add check on msg[0].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az602
n msg[0].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()") Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7a41ecfc3415ebe3b4c44f96b3337691dcf431a3 - https://git.kernel.org/stable/c/b3d77a3fc71c084575d3df4ec6544b3fb6ce587d - https://git.kernel.org/stable/c/17b30e5ded062bd74f8ca6f317e1d415a8680665 - https://git.kernel.org/stable/c/454a443eaa792c8865c861a282fe6d4f596abc3a - https://git.kernel.org/stable/c/6bbaec6a036940e22318f0454b50b8000845ab59 - https://git.kernel.org/stable/c/f98132a59ccc59a8b97987363bc99c8968934756 - https://git.kernel.org/stable/c/99690a494d91a0dc86
://git.kernel.org/stable/c/f98132a59ccc59a8b97987363bc99c8968934756 - https://git.kernel.org/stable/c/99690a494d91a0dc86cebd628da4c62c40552bcb - https://git.kernel.org/stable/c/39b06b93f24dff923c4183d564ed28c039150554 - https://git.kernel.org/stable/c/ed0234c8458b3149f15e496b48a1c9874dd24a1b
CVE ID: CVE-2025-38694 State: PUBLISHED Published: 2025-09-04T15:32:47.449Z Last Updated: 2025-11-03T17:41:20.959Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb() In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add check on msg[0].len to prevent crash. Similar issue occurs when access msg[1].buf[0] and msg[1].buf[1]. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027:
issue occurs when access msg[1].buf[0] and msg[1].buf[1]. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()") Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/bc07cae4f36bb18d5b6a9ed835c1278ca44ec82e - https://git.kernel.org/stable/c/ce8b7c711b9c4f040b5419729d0972db8e374324 - https://git.kernel.org/stable/c/529fd5593b721e6f4370c591f5086649ed149ff6 - https://git.kernel.org/stable/c/c33280d6bd668dbdc5a5f07887cc63a52ab4789c - https://git.kernel.org/stable/c/09906650484a09b3a4d4b3d3065395856810becd - https://git.kernel.org/stable/c/0bb32863426afe0badac25c28d59021f211d0f48 - https://git.kernel.org/
3d3065395856810becd - https://git.kernel.org/stable/c/0bb32863426afe0badac25c28d59021f211d0f48 - https://git.kernel.org/stable/c/a0f744d6cdde81d7382e183f77a4080a39b206cd - https://git.kernel.org/stable/c/19eb5d8e6aa1169d368a4d69aae5572950deb89d - https://git.kernel.org/stable/c/ce5cac69b2edac3e3246fee03e8f4c2a1075238b
CVE ID: CVE-2025-38695 State: PUBLISHED Published: 2025-09-04T15:32:48.168Z Last Updated: 2025-11-03T17:41:22.934Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may occur before sli4_hba.hdwqs are allocated. This may result in a null pointer dereference when attempting to take the abts_io_buf_list_lock for the first hardware queue. Fix by adding a null ptr check on phba->sli4_hba.hdwq and early return because this sit
ck for the first hardware queue. Fix by adding a null ptr check on phba->sli4_hba.hdwq and early return because this situation means there must have been an error during port initialization. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6711ce7e9de4eb1a541ef30638df1294ea4267f8 - https://git.kernel.org/stable/c/74bdf54a847dab209d2a8f65852f59b7fa156175 - https://git.kernel.org/stable/c/5e25ee1ecec91c61a8acf938ad338399cad464de - https://git.kernel.org/stable/c/add68606a01dcccf18837a53e85b85caf0693b4b - https://git.kernel.org/stable/c/7925dd68807cc8fd755b04ca99e7e6f1c04392e8 - https://git.kernel.org/stable/c/571617f171f723b05f02d154a2e549a17eab4
table/c/7925dd68807cc8fd755b04ca99e7e6f1c04392e8 - https://git.kernel.org/stable/c/571617f171f723b05f02d154a2e549a17eab4935 - https://git.kernel.org/stable/c/d3f55f46bb37a8ec73bfe3cfe36e3ecfa2945dfa - https://git.kernel.org/stable/c/46a0602c24d7d425dd8e00c749cd64a934aac7ec - https://git.kernel.org/stable/c/6698796282e828733cde3329c887b4ae9e5545e9
CVE ID: CVE-2025-38696 State: PUBLISHED Published: 2025-09-04T15:32:48.973Z Last Updated: 2025-11-03T17:41:23.900Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: MIPS: Don't crash in stack_top() for tasks without ABI or vDSO Not all tasks have an ABI associated or vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL ABI pointer and crash. This can for example happen when using kunit: mips_stack_top+0x28/0xc0 arch_pick_mmap_layout+0x190/0x220 kunit_vm_mmap_init+0xf8/0x138 __kunit_add_resource+0x40/0xa8 kunit_vm_mmap+0x88/0xd8 usercopy_test_init+0xb8/0x240 kunit_t
nit_vm_mmap_init+0xf8/0x138 __kunit_add_resource+0x40/0xa8 kunit_vm_mmap+0x88/0xd8 usercopy_test_init+0xb8/0x240 kunit_try_run_case+0x5c/0x1a8 kunit_generic_run_threadfn_adapter+0x28/0x50 kthread+0x118/0x240 ret_from_kernel_thread+0x14/0x1c Only dereference the ABI point if it is set. The GIC page is also included as it is specific to the vDSO. Also move the randomization adjustment into the same conditional. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ab18e48a503230d675e824a0d68a108bdff42503 - https://git.kernel.org/stable/c/e78033e59444d257d095b73ce5d20625294f6ec2 - https://git.kernel.org/stable/c/bd90dbd196831f5c2620736dc221db2634cf1e8e
le/c/e78033e59444d257d095b73ce5d20625294f6ec2 - https://git.kernel.org/stable/c/bd90dbd196831f5c2620736dc221db2634cf1e8e - https://git.kernel.org/stable/c/5b6839b572b503609b9b58bc6c04a816eefa0794 - https://git.kernel.org/stable/c/f22de2027b206ddfb8a075800bb5d0dacf2da4b8 - https://git.kernel.org/stable/c/82d140f6aab5e89a9d3972697a0dbe1498752d9b - https://git.kernel.org/stable/c/24d098b6f69b0aa806ffcb3e18259bee31650b28 - https://git.kernel.org/stable/c/cddf47d20b0325dc8a4e57b833fe96e8f36c42a4 - https://git.kernel.org/stable/c/e9f4a6b3421e936c3ee9d74710243897d74dbaa2
CVE ID: CVE-2025-38697 State: PUBLISHED Published: 2025-09-04T15:32:49.848Z Last Updated: 2025-11-03T17:41:26.028Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: upper bound check of tree index in dbAllocAG When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5bdb9553fb134fd52ec208a8b378120670f6e784 - https://git.kernel.org/stable/c/a4f199203f79ca9cd7355799ccb26800174ff093 - https://git.
134fd52ec208a8b378120670f6e784 - https://git.kernel.org/stable/c/a4f199203f79ca9cd7355799ccb26800174ff093 - https://git.kernel.org/stable/c/1467a75819e41341cd5ebd16faa2af1ca3c8f4fe - https://git.kernel.org/stable/c/49ea46d9025aa1914b24ea957636cbe4367a7311 - https://git.kernel.org/stable/c/173cfd741ad7073640bfb7e2344c2a0ee005e769 - https://git.kernel.org/stable/c/c8ca21a2836993d7cb816668458e05e598574e55 - https://git.kernel.org/stable/c/2dd05f09cc323018136a7ecdb3d1007be9ede27f - https://git.kernel.org/stable/c/30e19a884c0b11f33821aacda7e72e914bec26ef - https://git.kernel.org/stable/c/c214006856ff52a8ff17ed8da52d50601d54f9ce
CVE ID: CVE-2025-38698 State: PUBLISHED Published: 2025-09-04T15:32:50.616Z Last Updated: 2025-11-03T17:41:27.948Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: Regular file corruption check The reproducer builds a corrupted file on disk with a negative i_size value. Add a check when opening this file to avoid subsequent operation failures. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9f896c3d0192241d6438be6963682ace8203f502 - https://git.kernel.org/stable/c/6bc86f1d7d5419d5b19483ba203ca0b760c41c51 - https://git.kernel.org/stable/c/9ad054cd2c4ca8c371e555748832aa217c41fc6
ble/c/6bc86f1d7d5419d5b19483ba203ca0b760c41c51 - https://git.kernel.org/stable/c/9ad054cd2c4ca8c371e555748832aa217c41fc65 - https://git.kernel.org/stable/c/9605cb2ea38ba014d0e704cba0dbbb00593fa9fd - https://git.kernel.org/stable/c/78989af5bbf55a0cf1165b0fa73921bc02f1543b - https://git.kernel.org/stable/c/00462be586b33076f8b8023e7ba697deedc131db - https://git.kernel.org/stable/c/fd9454b7710b28060faa49b041f8283c435721a3 - https://git.kernel.org/stable/c/02edcfda419168d9405bffe55f18ea9c1bf92366 - https://git.kernel.org/stable/c/2d04df8116426b6c7b9f8b9b371250f666a2a2fb
CVE ID: CVE-2025-38699 State: PUBLISHED Published: 2025-09-04T15:32:51.420Z Last Updated: 2025-11-03T17:41:29.823Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Double-free fix When the bfad_im_probe() function fails during initialization, the memory pointed to by bfad->im is freed without setting bfad->im to NULL. Subsequently, during driver uninstallation, when the state machine enters the bfad_sm_stopping state and calls the bfad_im_probe_undo() function, it attempts to free the memory pointed to by bfad->im again, thereby triggering a double-free vulnerability. Set bfad->im to NULL if probing fails. Additional A
o by bfad->im again, thereby triggering a double-free vulnerability. Set bfad->im to NULL if probing fails. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/684c92bb08a25ed3c0356bc7eb532ed5b19588dd - https://git.kernel.org/stable/c/9337c2affbaebe00b75fdf84ea0e2fcf93c140af - https://git.kernel.org/stable/c/ba024d92564580bb90ec367248ace8efe16ce815 - https://git.kernel.org/stable/c/8e03dd9fadf76db5b9799583074a1a2a54f787f1 - https://git.kernel.org/stable/c/39cfe2c83146aad956318f866d0ee471b7a61fa5 - https://git.kernel.org/stable/c/13f613228cf3c96a038424cd97aa4d6aadc66294 - https://git.kernel.org/stable/c/8456f862cb95bcc3a831e1ba87c0c17068be0f3f - ht
13f613228cf3c96a038424cd97aa4d6aadc66294 - https://git.kernel.org/stable/c/8456f862cb95bcc3a831e1ba87c0c17068be0f3f - https://git.kernel.org/stable/c/50d9bd48321038bd6e15af5a454bbcd180cf6f80 - https://git.kernel.org/stable/c/add4c4850363d7c1b72e8fce9ccb21fdd2cf5dc9
CVE ID: CVE-2025-38700 State: PUBLISHED Published: 2025-09-04T15:32:52.241Z Last Updated: 2025-11-03T17:41:31.738Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown. Fix by setting iscsi_conn->dd_data only if memory is actually allocated. Panic trace: ------------ iser: iser_create_fastreg_desc:
ting iscsi_conn->dd_data only if memory is actually allocated. Panic trace: ------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_f
nk_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f53af99f441ee79599d8df6113a7144d74cf9153 - https://git.kernel.org/stable/c/9ea6d961566c7d762ed0204b06db05756fdda3b6 - https://git.kernel.org/stable/c/fd5aad080edb501ab5c84b7623d612d0e3033403 - https://git.kernel.org/stable/c/a145c269dc5380c063a20a0db7e6df2995962e9d - https://git.kernel.org/stable/c/66a373f50b4249d57f5a88c7be9676f9d5884865 - https://git.kernel.org/stable/c/35782c32528d82aa21f84cb5ceb2abd3526a8159 - https://git.kernel.org/