Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-35814 State: PUBLISHED Published: 2024-05-17T13:23:19.590Z Last Updated: 2025-05-04T09:05:58.509Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: swiotlb: Fix double-allocation of slots due to broken alignment handling Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"), which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment checks"), causes a functional regression with vsock in a virtual machine using bouncing via a restricted DMA SWIOTLB pool. When virtio allocates the virtqueues for the vsock device using dma_alloc_coherent(), the SWIOTLB search can return page-unaligned al
llocates the virtqueues for the vsock device using dma_alloc_coherent(), the SWIOTLB search can return page-unaligned allocations if 'area->index' was left unaligned by a previous allocation from the buffer: # Final address in brackets is the SWIOTLB address returned to the caller | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800) This ends badly (typic
dr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800) This ends badly (typically buffer corruption and/or a hang) because swiotlb_alloc() is expecting a page-aligned allocation and so blindly returns a pointer to the 'struct page' corresponding to the allocation, therefore double-allocating the first half (2KiB slot) of the 4KiB page. Fix the problem by treating the allocation alignment separately to any additional alignment requirements from the device, using the maximum of the two as the stride to search the buffer slots and taking care to ensure a minimum of page-alignment for buffers larger than a page. This also resolves swiotlb allocation fai
ing care to ensure a minimum of page-alignment for buffers larger than a page. This also resolves swiotlb allocation failures occuring due to the inclusion of ~PAGE_MASK in 'iotlb_align_mask' for large allocations and resulting in alignment requirements exceeding swiotlb_max_mapping_size(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3e7acd6e25ba77dde48c3b721c54c89cd6a10534 - https://git.kernel.org/stable/c/c88668aa6c1da240ea3eb4d128b7906e740d3cb8 - https://git.kernel.org/stable/c/777391743771040e12cc40d3d0d178f70c616491 - https://git.kernel.org/stable/c/04867a7a33324c9c562ee7949dbcaab7aaad1fb4
CVE ID: CVE-2024-35815 State: PUBLISHED Published: 2024-05-17T13:23:20.326Z Last Updated: 2025-05-04T09:05:59.810Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion The first kiocb_set_cancel_fn() argument may point at a struct kiocb that is not embedded inside struct aio_kiocb. With the current code, depending on the compiler, the req->ki_ctx read happens either before the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such that it is guaranteed that the IOCB_AIO_RW test happens first. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program
is guaranteed that the IOCB_AIO_RW test happens first. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/10ca82aff58434e122c7c757cf0497c335f993f3 - https://git.kernel.org/stable/c/396dbbc18963648e9d1a4edbb55cfe08fa374d50 - https://git.kernel.org/stable/c/94eb0293703ced580f05dfbe5a57da5931e9aee2 - https://git.kernel.org/stable/c/a71cba07783abc76b547568b6452cd1dd9981410 - https://git.kernel.org/stable/c/18d5fc3c16cc317bd0e5f5dabe0660df415cadb7 - https://git.kernel.org/stable/c/c01ed748847fe8b810d86efc229b9e6c7fafa01e - https://git.kernel.org/stable/c/5c43d0041e3a05c6c41c318b759fff16d2384596 - https://git.kernel.org/stable/
9e6c7fafa01e - https://git.kernel.org/stable/c/5c43d0041e3a05c6c41c318b759fff16d2384596 - https://git.kernel.org/stable/c/961ebd120565cb60cebe21cb634fbc456022db4a
CVE ID: CVE-2024-35816 State: PUBLISHED Published: 2024-05-17T13:23:21.051Z Last Updated: 2025-05-04T09:06:03.263Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firewire: ohci: prevent leak of left-over IRQ on unbind Commit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ") also removed the call to free_irq() in pci_remove(), leading to a leftover irq of devm_request_irq() at pci_disable_msi() in pci_remove() when unbinding the driver from the device remove_proc_entry: removing non-empty directory 'irq/136', leaking at least 'firewire_ohci' Call Trace: ? remove_proc_entry+0x19c/0x1c0 ? __warn+0x81/0x130 ? remove
ory 'irq/136', leaking at least 'firewire_ohci' Call Trace: ? remove_proc_entry+0x19c/0x1c0 ? __warn+0x81/0x130 ? remove_proc_entry+0x19c/0x1c0 ? report_bug+0x171/0x1a0 ? console_unlock+0x78/0x120 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? remove_proc_entry+0x19c/0x1c0 unregister_irq_proc+0xf4/0x120 free_desc+0x3d/0xe0 ? kfree+0x29f/0x2f0 irq_free_descs+0x47/0x70 msi_domain_free_locked.part.0+0x19d/0x1d0 msi_domain_free_irqs_all_locked+0x81/0xc0 pci_free_msi_irqs+0x12/0x40 pci_disable_msi+0x4c/0x60 pci_remove+0x9d/0xc0 [firewire_ohci 01b483699bebf9cb07a3d69df0aa2bee71db1b26] pci_device_remove+0x37/0xa0 device_release_driver_internal+0x19f/0x200 unbind_
01b483699bebf9cb07a3d69df0aa2bee71db1b26] pci_device_remove+0x37/0xa0 device_release_driver_internal+0x19f/0x200 unbind_store+0xa1/0xb0 remove irq with devm_free_irq() before pci_disable_msi() also remove it in fail_msi: of pci_probe() as this would lead to an identical leak Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/43c70cbc2502cf2557105c662eeed6a15d082b88 - https://git.kernel.org/stable/c/318f6d53dd425c400e35f1a9b7af682c2c6a66d6 - https://git.kernel.org/stable/c/575801663c7dc38f826212b39e3b91a4a8661c33
CVE ID: CVE-2024-35817 State: PUBLISHED Published: 2024-05-17T13:23:21.720Z Last Updated: 2025-05-21T09:12:35.522Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgpu_ttm_backend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Contai
t, harder to debug and reproduce the real issue. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/5d5f1a7f3b1039925f79c7894f153c2a905201fb - https://git.kernel.org/stable/c/589c414138a1bed98e652c905937d8f790804efe - https://git.kernel.org/stable/c/6fcd12cb90888ef2d8af8d4c04e913252eee4ef3 - https://git.kernel.org/stable/c/e8d27caef2c829a306e1f762fb95f06e8ec676f6 - https://git.kernel.org/stable/c/5cdce3dda3b3dacde902f63a8ee72c2b7f91912d - https://git.kernel.org/stable/c/6c6064cbe58b43533e3451ad6a8ba9736c109ac3
CVE ID: CVE-2024-35818 State: PUBLISHED Published: 2024-05-17T13:23:22.370Z Last Updated: 2025-05-04T09:06:06.109Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Define the __io_aw() hook as mmiowb() Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says: "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on
ock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation." The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio. So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defin
be other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). And we no longer need to override queued_spin_unlock() so use the generic definition. Without this, we get such an error when run 'glxgears' on weak ordering architectures such as LoongArch: radeon 0000:04:00.0: ring 0 stalled for more than 10324msec radeon 0000:04:00.0: ring 3 stalled for more than 10240msec radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3) radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon
radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update
BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167 - https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d - https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0 - https://git.
875be3b241d7d39873bb431db7154d - https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0 - https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb - https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd
CVE ID: CVE-2024-35819 State: PUBLISHED Published: 2024-05-17T13:23:23.031Z Last Updated: 2025-05-04T12:55:49.933Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Use raw spinlock for cgr_lock smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task. Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link g
Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2b3fede8225133671ce837c0d284804aa3bc7a02 - https://git.kernel.org/stable/c/ff50716b7d5b7985979a5b21163cd79fb3d21d59 - https://git.kernel.org/stable/c/32edca2f03a6cc42c650ddc3ad83d086e3f365d1 - https://git.kernel.org/stable/c/9a3ca8292ce9fdcce122706c28c3f07bc857fe5e - https://git.kernel.org/stable/c/d6b5aac451c9cc12e43ab7308e0e2ddc52c62c14 - https://git.kernel.org/stable/c/54d26adf64c04f186098b39dba86b86037084baa - https://git.kernel.org/s
308e0e2ddc52c62c14 - https://git.kernel.org/stable/c/54d26adf64c04f186098b39dba86b86037084baa - https://git.kernel.org/stable/c/f39d36b7540cf0088ed7ce2de2794f2aa237f6df - https://git.kernel.org/stable/c/cd53a8ae5aacb4ecd25088486dea1cd02e74b506 - https://git.kernel.org/stable/c/fbec4e7fed89b579f2483041fabf9650fb0dd6bc
CVE ID: CVE-2024-35820 State: REJECTED Published: 2024-05-17T13:23:23.686Z Last Updated: 2024-05-25T13:30:44.059Z Description: No description available.
CVE ID: CVE-2024-35821 State: PUBLISHED Published: 2024-05-17T13:23:24.350Z Last Updated: 2025-05-04T09:06:08.823Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ubifs: Set page uptodate in the correct place Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable
Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e - https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310 - https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f - https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3 - https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3 - https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f - https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa02e675e - https://git.kernel.org/stable/c/17772bbe9cfa972ea1ff827319f6e1340de76566 - https://g
60d6a46350fbe54f5dc937aeaa02e675e - https://git.kernel.org/stable/c/17772bbe9cfa972ea1ff827319f6e1340de76566 - https://git.kernel.org/stable/c/723012cab779eee8228376754e22c6594229bf8f
CVE ID: CVE-2024-35822 State: PUBLISHED Published: 2024-05-17T13:23:24.994Z Last Updated: 2025-05-04T09:06:10.159Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: udc: remove warning when queue disabled ep It is possible trigger below warning message from mass storage function, WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable. As there is no function failure in the driver, in order to avoid
er thread may already disable ep when function disable. As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2b002c308e184feeaeb72987bca3f1b11e5f70b8 - https://git.kernel.org/stable/c/68d951880d0c52c7f13dcefb5501b69b8605ce8c - https://git.kernel.org/stable/c/3e944ddc17c042945d983e006df7860687a8849a - https://git.kernel.org/stable/c/df5cbb908f1687e8ab97e222a16b7890d5501acf - https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf - https://git.kernel.org/stable/c/9973
501acf - https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf - https://git.kernel.org/stable/c/99731076722eb7ed26b0c87c879da7bb71d24290 - https://git.kernel.org/stable/c/36177c2595df12225b95ce74eb1ac77b43d5a58c - https://git.kernel.org/stable/c/30511676eb54d480d014352bf784f02577a10252 - https://git.kernel.org/stable/c/2a587a035214fa1b5ef598aea0b81848c5b72e5e
CVE ID: CVE-2024-35823 State: PUBLISHED Published: 2024-05-17T13:23:25.651Z Last Updated: 2025-05-04T09:06:11.480Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vt: fix unicode buffer corruption when deleting characters This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d - http
: - CVE Program Container: References: - https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d - https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a - https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90 - https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f - https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51 - https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda - https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85f237ff1 - https://git.kernel.org/stable/c/1581dafaf0d34bc9c428a794a22110d7046d186d
CVE ID: CVE-2024-35824 State: PUBLISHED Published: 2024-05-17T13:27:25.357Z Last Updated: 2025-05-04T09:06:12.860Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: misc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume When not configured for wakeup lis3lv02d_i2c_suspend() will call lis3lv02d_poweroff() even if the device has already been turned off by the runtime-suspend handler and if configured for wakeup and the device is runtime-suspended at this point then it is not turned back on to serve as a wakeup source. Before commit b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl cal
n to serve as a wakeup source. Before commit b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback"), lis3lv02d_poweroff() failed to disable the regulators which as a side effect made calling poweroff() twice ok. Now that poweroff() correctly disables the regulators, doing this twice triggers a WARN() in the regulator core: unbalanced disables for regulator-dummy WARNING: CPU: 1 PID: 92 at drivers/regulator/core.c:2999 _regulator_disable ... Fix lis3lv02d_i2c_suspend() to not call poweroff() a second time if already runtime-suspended and add a poweron() call when necessary to make wakeup work. lis3lv02d_i2c_resume() has similar issues, with an added weirness that i
eron() call when necessary to make wakeup work. lis3lv02d_i2c_resume() has similar issues, with an added weirness that it always powers on the device if it is runtime suspended, after which the first runtime-resume will call poweron() again, causing the enabled count for the regulator to increase by 1 every suspend/resume. These unbalanced regulator_enable() calls cause the regulator to never be turned off and trigger the following WARN() on driver unbind: WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put Fix this by making lis3lv02d_i2c_resume() mirror the new suspend(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https:/
ror the new suspend(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/4154e767354140db7804207117e7238fb337b0e7 - https://git.kernel.org/stable/c/997ca415384612c8df76d99d9a768e0b3f42b325 - https://git.kernel.org/stable/c/f6df761182fc953907b18aba5049fc2a044ecb45 - https://git.kernel.org/stable/c/ac3e0384073b2408d6cb0d972fee9fcc3776053d
CVE ID: CVE-2024-35825 State: PUBLISHED Published: 2024-05-17T13:27:28.914Z Last Updated: 2025-05-04T12:55:50.991Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Fix handling of zero block length packets While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present. According to the NCM spec: "If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbIn
h = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent. wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues. wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue
he sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e2dbfea520e60d58e0c498ba41bde10452257779 - https://git.kernel.org/stable/c/a766761d206e7c36d7526e
it.kernel.org/stable/c/e2dbfea520e60d58e0c498ba41bde10452257779 - https://git.kernel.org/stable/c/a766761d206e7c36d7526e0ae749949d17ca582c - https://git.kernel.org/stable/c/ef846cdbd100f7f9dc045e8bcd7fe4b3a3713c03 - https://git.kernel.org/stable/c/92b051b87658df7649ffcdef522593f21a2b296b - https://git.kernel.org/stable/c/7664ee8bd80309b90d53488b619764f0a057f2b7 - https://git.kernel.org/stable/c/a0f77b5d6067285b8eca0ee3bd1e448a6258026f - https://git.kernel.org/stable/c/6b2c73111a252263807b7598682663dc33aa4b4c - https://git.kernel.org/stable/c/f90ce1e04cbcc76639d6cba0fdbd820cd80b3c70
CVE ID: CVE-2024-35826 State: PUBLISHED Published: 2024-05-17T13:27:32.383Z Last Updated: 2025-05-04T12:55:52.035Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: Fix page refcounts for unaligned buffers in __bio_release_pages() Fix an incorrect number of pages being released for buffers that do not start at the beginning of a page. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/242006996d15f5ca62e22f8c7de077d9c4a8f367 - https://git.kernel.org/stable/c/7d3765550374f71248c55e6206ea1d6fd4537e65 - https://git.kernel.org/stable/c/ecbd9ced84dd655a8f4cd4
it.kernel.org/stable/c/7d3765550374f71248c55e6206ea1d6fd4537e65 - https://git.kernel.org/stable/c/ecbd9ced84dd655a8f4cd49d2aad0e80dbf6bf35 - https://git.kernel.org/stable/c/c9d3d2fbde9b8197bce88abcbe8ee8e713ffe7c2 - https://git.kernel.org/stable/c/38b43539d64b2fa020b3b9a752a986769f87f7a6