Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
translated to an invalid register - 0xca0 in this scenario. Fix it by clearing staged_config[] before and after it is used. [reinette: re-order commit tags] References: - https://git.kernel.org/stable/c/86db319d25db70cf4af4557e05f6fa6f39c70003 - https://git.kernel.org/stable/c/3fc5941ecc31a495b6b84b465f36155009db99b5 - https://git.kernel.org/stable/c/8ecc60ef9318f0d533b866fa421858cc185bccfc - https://git.kernel.org/stable/c/0424a7dfe9129b93f29b277511a60e87f052ac6b
CVE ID: CVE-2023-53170 State: PUBLISHED Published: 2025-09-15T14:04:03.446Z Last Updated: 2025-09-15T14:04:03.446Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: Removed unneeded of_node_put in felix_parse_ports_node Remove unnecessary of_node_put from the continue path to prevent child node from being released twice, which could avoid resource leak or other unexpected issues. References: - https://git.kernel.org/stable/c/7ead10b44b79ce8bfcd51e749d54e009de5f511a - https://git.kernel.org/stable/c/04499f28b40bfc24f20b0e2331008bb90a54a6cf
CVE ID: CVE-2023-53171 State: PUBLISHED Published: 2025-09-15T14:04:04.544Z Last Updated: 2025-09-15T14:04:04.544Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vfio/type1: prevent underflow of locked_vm via exec() When a vfio container is preserved across exec, the task does not change, but it gets a new mm with locked_vm=0, and loses the count from existing dma mappings. If the user later unmaps a dma mapping, locked_vm underflows to a large unsigned value, and a subsequent dma map request fails with ENOMEM in __account_locked_vm. To avoid underflow, grab and save the mm at the time a dma is mapped. Use that mm when adjustin
in __account_locked_vm. To avoid underflow, grab and save the mm at the time a dma is mapped. Use that mm when adjusting locked_vm, rather than re-acquiring the saved task's mm, which may have changed. If the saved mm is dead, do nothing. locked_vm is incremented for existing mappings in a subsequent patch. References: - https://git.kernel.org/stable/c/5a271242716846cc016736fb76be2b40ee49b0c3 - https://git.kernel.org/stable/c/eafb81c50da899dd80b340c841277acc4a1945b7 - https://git.kernel.org/stable/c/a6b2aabe664098d5cf877ae0fd96459464a30e17 - https://git.kernel.org/stable/c/b0790dff0760b7734cf0961f497ad64628ca550b - https://git.kernel.org/stable/c/046eca5018f8a5dd1dc2cedf87fb5843b9ea3026
CVE ID: CVE-2023-53172 State: PUBLISHED Published: 2025-09-15T14:04:06.075Z Last Updated: 2025-09-15T14:04:06.075Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds Commit 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE") changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read the file's data, instead of direct pagecache accesses. An unintended consequence of this is that the 'WARN_ON_ONCE(!(file->f_mode & FMODE_READ))' in __kernel_read() became reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called on a fd opened with access mode 3
_read() became reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called on a fd opened with access mode 3, which means "ioctl access only". Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But ioctl-only fds are a weird Linux extension that is rarely used and that few people even know about. (The documentation for FS_IOC_ENABLE_VERITY even specifically says it requires O_RDONLY.) It's probably not worthwhile to make the ioctl internally open a new fd just to handle this case. Thus, just reject the ioctl on such fds for now. References: - https://git.kernel.org/stable/c/85c039cff3c359967cafe90443c02321e950b216 - https://git.kernel.org/stable/c/04839139213cf60d4c5fc
git.kernel.org/stable/c/85c039cff3c359967cafe90443c02321e950b216 - https://git.kernel.org/stable/c/04839139213cf60d4c5fc792214a08830e294ff8
CVE ID: CVE-2023-53173 State: PUBLISHED Published: 2025-09-15T14:04:07.411Z Last Updated: 2025-09-15T14:04:07.411Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tty: pcn_uart: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. References: - https://git.kernel.org/stable/c/cf042964c2fa72950bbbf25b2cdd732b873e89db - https://git.kernel.org/stable/c/4459d1e7bd0421b3b6fcd745773d8823f71615ef - https://git.kernel.org/sta
2cdd732b873e89db - https://git.kernel.org/stable/c/4459d1e7bd0421b3b6fcd745773d8823f71615ef - https://git.kernel.org/stable/c/139769c4bd8273b5e3f85ea474aa37018fe7e436 - https://git.kernel.org/stable/c/04a189c720aa2b6091442113ce9b9bc93552dff8
CVE ID: CVE-2023-53174 State: PUBLISHED Published: 2025-09-15T14:04:08.357Z Last Updated: 2025-09-15T14:04:08.357Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix possible memory leak if device_add() fails If device_add() returns error, the name allocated by dev_set_name() needs be freed. As the comment of device_add() says, put_device() should be used to decrease the reference count in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanp(). References: - https://git.kernel.org/stable/c/63956ad27a6882f01fea7c69e17823090f4c7b3f - https://git.kernel.org/stable/c/06c53408
s: - https://git.kernel.org/stable/c/63956ad27a6882f01fea7c69e17823090f4c7b3f - https://git.kernel.org/stable/c/06c5340858011aa1195aec43a776e3185fbf7f56 - https://git.kernel.org/stable/c/e12fac07f61caac9c5b186d827658b3470787619 - https://git.kernel.org/stable/c/aa9a76d5ffdecd3b52ac333eb89361b0c9fe04e8 - https://git.kernel.org/stable/c/6bc7f4c8c27d526f968788b8a985896755b1df35 - https://git.kernel.org/stable/c/b191ff1f075c4875f11271cbf0093e6e044a12aa - https://git.kernel.org/stable/c/43c0e16d0c5ec59398b405f4c4aa5a076e656c3f - https://git.kernel.org/stable/c/04b5b5cb0136ce970333a9c6cec7e46adba1ea3a
CVE ID: CVE-2023-53175 State: PUBLISHED Published: 2025-09-15T14:04:09.618Z Last Updated: 2025-09-15T14:04:09.618Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the device yet), doing a VM hibernation triggers a panic in hv_pci_restore_msi_msg() -> msi_lock_descs(&pdev->dev), because pdev->dev.msi.data is still NULL. Avoid the panic by checking if MSI-X/MSI is enabled. References: - https://git.kernel.org/stable/c/223fc53520
till NULL. Avoid the panic by checking if MSI-X/MSI is enabled. References: - https://git.kernel.org/stable/c/223fc5352054900f70b8b5e10cfc2f297e70c512 - https://git.kernel.org/stable/c/d0687755407b21d252b98dca6be459153a60c62a - https://git.kernel.org/stable/c/e32fc2168aa6b477290392ddbb73d95f012b050c - https://git.kernel.org/stable/c/04bbe863241a9be7d57fb4cf217ee4a72f480e70
CVE ID: CVE-2023-53176 State: PUBLISHED Published: 2025-09-15T14:04:16.360Z Last Updated: 2025-09-15T14:04:16.360Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Reinit port->pm on port specific driver unbind When we unbind a serial port hardware specific 8250 driver, the generic serial8250 driver takes over the port. After that we see an oops about 10 seconds later. This can produce the following at least on some TI SoCs: Unhandled fault: imprecise external abort (0x1406) Internal error: : 1406 [#1] SMP ARM Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_p
[#1] SMP ARM Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_pm() tries to call it after the port specific driver is gone: serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c disassociate_ctty from do_exit+0x744/0xaac do_exit from do_group_exit+0x40/0x8c do_group_exit from __wake_up_parent+0x0/0x1c Let's fix the issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the ser
issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the serial8250 default functions, and sets the port->pm to point to serial8250_pm. References: - https://git.kernel.org/stable/c/490bf37eaabb0a857ed1ae8e75d8854e41662f1c - https://git.kernel.org/stable/c/c9e080c3005fd183c56ff8f4d75edb5da0765d2c - https://git.kernel.org/stable/c/d5cd2928d31042a7c0a01464f9a8d95be736421d - https://git.kernel.org/stable/c/2c86a1305c1406f45ea780d06953c484ea1d9e6e - https://git.kernel.org/stable/c/1ba5594739d858e524ff0f398ee1ebfe0a8b9d41 - https://git.kernel.org/stable/c/af4d6dbb1a92ea424ad1ba1d0c88c7fa2345d872 - https://git.kernel.org/stable/c/8e596aed
41 - https://git.kernel.org/stable/c/af4d6dbb1a92ea424ad1ba1d0c88c7fa2345d872 - https://git.kernel.org/stable/c/8e596aed5f2f98cf3e6e98d6fe1d689f4a319308 - https://git.kernel.org/stable/c/04e82793f068d2f0ffe62fcea03d007a8cdc16a7
CVE ID: CVE-2023-53177 State: PUBLISHED Published: 2025-09-15T14:04:20.626Z Last Updated: 2025-09-15T14:04:20.626Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: hi846: fix usage of pm_runtime_get_if_in_use() pm_runtime_get_if_in_use() does not only return nonzero values when the device is in use, it can return a negative errno too. And especially during resuming from system suspend, when runtime pm is not yet up again, -EAGAIN is being returned, so the subsequent pm_runtime_put() call results in a refcount underflow. Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use(). References: - https://git.kernel.or
ount underflow. Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use(). References: - https://git.kernel.org/stable/c/42ec6269f98edd915ee37da3c6456bb6243ea56a - https://git.kernel.org/stable/c/c5dcd7a19f1ed8fe98384f3a9444c7c53befd74e - https://git.kernel.org/stable/c/04fc06f6dc1592ed5d675311ac50d8fba5db62ab
CVE ID: CVE-2023-53178 State: PUBLISHED Published: 2025-09-15T14:04:23.768Z Last Updated: 2025-09-16T08:02:20.669Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: fix zswap writeback race condition The zswap writeback mechanism can cause a race condition resulting in memory corruption, where a swapped out page gets swapped in with data that was written to a different page. The race unfolds like this: 1. a page with data A and swap offset X is stored in zswap 2. page A is removed off the LRU by zpool driver for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates pa
for writeback in zswap-shrink work, data for A is mapped by zpool driver 3. user space program faults and invalidates page entry A, offset X is considered free 4. kswapd stores page B at offset X in zswap (zswap could also be full, if so, page B would then be IOed to X, then skip step 5.) 5. entry A is replaced by B in tree->rbroot, this doesn't affect the local reference held by zswap-shrink work 6. zswap-shrink work writes back A at X, and frees zswap entry A 7. swapin of slot X brings A in memory instead of B The fix: Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW), zswap-shrink work just checks that the local zswap_entry reference is still the same as the one in th
AP_SWAPCACHE_NEW), zswap-shrink work just checks that the local zswap_entry reference is still the same as the one in the tree. If it's not the same it means that it's either been invalidated or replaced, in both cases the writeback is aborted because the local entry contains stale data. Reproducer: I originally found this by running `stress` overnight to validate my work on the zswap writeback mechanism, it manifested after hours on my test machine. The key to make it happen is having zswap writebacks, so whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do the trick. In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M s
ld do the trick. In order to reproduce this faster on a vm, I setup a system with ~100M of available memory and a 500M swap file, then running `stress --vm 1 --vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens of minutes. One can speed things up even more by swinging /sys/module/zswap/parameters/max_pool_percent up and down between, say, 20 and 1; this makes it reproduce in tens of seconds. It's crucial to set `--vm-stride` to something other than 4096 otherwise `stress` won't realize that memory has been corrupted because all pages would have the same data. References: - https://git.kernel.org/stable/c/2cab13f500a6333bd2b853783ac76be9e4956f8a - https://git.kernel.org/st
data. References: - https://git.kernel.org/stable/c/2cab13f500a6333bd2b853783ac76be9e4956f8a - https://git.kernel.org/stable/c/ba700ea13bf0105a4773c654f7d3bef8adb64ab2 - https://git.kernel.org/stable/c/04fc7816089c5a32c29a04ec94b998e219dfb946
CVE ID: CVE-2023-53179 State: PUBLISHED Published: 2025-09-15T14:04:26.782Z Last Updated: 2025-09-15T14:04:26.782Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong `CIDR_POS(c)` for calculating array offsets, which can lead to integer underflow. As a result, it leads to slab out-of-bound access. This patch adds back the IP_SET_HASH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue. References: - https://git.kernel.org/stable/c/7935b63
SH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue. References: - https://git.kernel.org/stable/c/7935b636dd693dfe4483cfef4a1e91366c8103fa - https://git.kernel.org/stable/c/e632d09dffc68b9602d6893a99bfe3001d36cefc - https://git.kernel.org/stable/c/109e830585e89a03d554bf8ad0e668630d0a6260 - https://git.kernel.org/stable/c/83091f8ac03f118086596f17c9a52d31d6ca94b3 - https://git.kernel.org/stable/c/a9e6142e5f8f6ac7d1bca45c1b2b13b084ea9e14 - https://git.kernel.org/stable/c/7ca0706c68adadf86a36b60dca090f5e9481e808 - https://git.kernel.org/stable/c/d59b6fc405549f7caf31f6aa5da1d6bef746b166 - https://git.kernel.org/stable/c/d95c8420efe684b964e3aa28108e9a354bcd7225 - https://git.kernel.
f31f6aa5da1d6bef746b166 - https://git.kernel.org/stable/c/d95c8420efe684b964e3aa28108e9a354bcd7225 - https://git.kernel.org/stable/c/050d91c03b28ca479df13dfb02bcd2c60dd6a878
CVE ID: CVE-2023-53180 State: PUBLISHED Published: 2025-09-15T14:04:31.143Z Last Updated: 2025-09-16T08:02:22.024Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Avoid NULL pointer access during management transmit cleanup Currently 'ar' reference is not added in skb_cb. Though this is generally not used during transmit completion callbacks, on interface removal the remaining idr cleanup callback uses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them during transmit call for proper usage to avoid NULL pointer dereference. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 R
proper usage to avoid NULL pointer dereference. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 References: - https://git.kernel.org/stable/c/7382d02160ef93c806fe1c1d4ef1fec445266747 - https://git.kernel.org/stable/c/054b5580a36e435692c203c19abdcb9f7734320e
CVE ID: CVE-2023-53181 State: PUBLISHED Published: 2025-09-15T14:04:32.098Z Last Updated: 2025-09-15T14:04:32.098Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dma-buf/dma-resv: Stop leaking on krealloc() failure Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's ze
lers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure. References: - https://git.kernel.org/stable/c/19e7b9f1f7e1cb92a4cc53b4c064f7fb4b1f1983 - https://git.kernel.org/stable/c/819656cc03dec7f7f7800274dfbc8eb49f888e9f - https://git.kernel.org/stable/c/05abb3be91d8788328231ee02973ab3d47f5e3d2
CVE ID: CVE-2023-53182 State: PUBLISHED Published: 2025-09-15T14:04:33.101Z Last Updated: 2025-09-15T14:04:33.101Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPICA: Avoid undefined behavior: applying zero offset to null pointer ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #1.2 0x0
_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f #1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f #1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f #2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d #
t.asan.so>+0x4196d #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d #4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369 #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_p
d.c:605 <platform-bus-x86.so>+0x262369 #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac #7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2 #8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052 #9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bu
e_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8 #10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98 #11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac #12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d #13 0x0000
jects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d #13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603 Add a simple check that avoids incrementing a pointer by zero, but otherwise behaves as before. Note that our findings are against ACPICA 20221020, but the same code exists on master. References: - https://git.kernel.org/stable/c/5a2d0dcb47b16f84880a59571eab8a004e3236d7 - https://git.kernel.org/stable/c/35465c7a91c6b46e7c14d0c01d0084349a38ce51 - https://git.kernel.org/stable/c/710e09fd116e2fa53e319a416ad4e4f8027682b6 - https://gi
91c6b46e7c14d0c01d0084349a38ce51 - https://git.kernel.org/stable/c/710e09fd116e2fa53e319a416ad4e4f8027682b6 - https://git.kernel.org/stable/c/16359bc02c093b0862e31739c07673340a2106a6 - https://git.kernel.org/stable/c/3a7a4aa3958ce0c4938a443d65001debe9a9af9c - https://git.kernel.org/stable/c/8c4a7163b7f1495e3cc58bec7a4100de6612cde9 - https://git.kernel.org/stable/c/3048c6b84a51e4ba4a89385ed218d19a670edd47 - https://git.kernel.org/stable/c/05bb0167c80b8f93c6a4e0451b7da9b96db990c2
CVE ID: CVE-2023-53183 State: PUBLISHED Published: 2025-09-15T14:04:35.399Z Last Updated: 2025-09-15T14:04:35.399Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: exit gracefully if reloc roots don't match [BUG] Syzbot reported a crash that an ASSERT() got triggered inside prepare_to_merge(). [CAUSE] The root cause of the triggered ASSERT() is we can have a race between quota tree creation and relocation. This leads us to create a duplicated quota tree in the btrfs_read_fs_root() path, and since it's treated as fs tree, it would have ROOT_SHAREABLE flag, causing us to create a reloc tree for it. The bug itself is fixed by
ated as fs tree, it would have ROOT_SHAREABLE flag, causing us to create a reloc tree for it. The bug itself is fixed by a dedicated patch for it, but this already taught us the ASSERT() is not something straightforward for developers. [ENHANCEMENT] Instead of using an ASSERT(), let's handle it gracefully and output extra info about the mismatch reloc roots to help debug. Also with the above ASSERT() removed, we can trigger ASSERT(0)s inside merge_reloc_roots() later. Also replace those ASSERT(0)s with WARN_ON()s. References: - https://git.kernel.org/stable/c/69dd147de419b04d1d8d2ca67ef424cddd5b8fd5 - https://git.kernel.org/stable/c/9d04716e36654275aea00fb93fc9b30b850925e7 - https://git.kern
4d1d8d2ca67ef424cddd5b8fd5 - https://git.kernel.org/stable/c/9d04716e36654275aea00fb93fc9b30b850925e7 - https://git.kernel.org/stable/c/a96b6519ac71583835cb46d74bc450de5a13877f - https://git.kernel.org/stable/c/05d7ce504545f7874529701664c90814ca645c5d
CVE ID: CVE-2023-53184 State: PUBLISHED Published: 2025-09-15T14:04:36.754Z Last Updated: 2025-09-15T14:04:36.754Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64/sme: Set new vector length before reallocating As part of fixing the allocation of the buffer for SVE state when changing SME vector length we introduced an immediate reallocation of the SVE state, this is also done when changing the SVE vector length for consistency. Unfortunately this reallocation is done prior to writing the new vector length to the task struct, meaning the allocation is done with the old vector length and can lead to memory corruption due to