Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ers of a packet to be delivered without any interleaving. The following GICv3 commands may result in multiple transfer packets over inter-socket AXI4 Stream interface: - Register reads from GICD_I* and GICD_N* - Register writes to 64-bit GICD registers other than GICD_IROUTERn* - ITS command MOVALL Multiple commands in GICv4+ utilize multiple transfer packets, including VMOVP, VMOVI, VMAPP, and 64-bit register accesses." This issue impacts system configurations with more than 2 sockets, that require multi-transfer packets to be sent over inter-socket AXI4 Stream interface between GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the work
etween GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the workaround. Single and Dual socket configurations are not impacted by this issue and support GICv3 and GICv4." Writing to the chip alias region of the GICD_In{E} registers except GICD_ICENABLERn has an equivalent effect as writing to the global distributor. The SPI interrupt deactivate path is not impacted by the erratum. To fix this problem, implement a workaround that ensures read accesses to the GICD_In{E} registers are directed to the chip that owns the SPI, and disable GICv4.x features. To simplify code changes, the gic_configure_irq() function uses the same alias region f
I, and disable GICv4.x features. To simplify code changes, the gic_configure_irq() function uses the same alias region for both read and write operations to GICD_ICFGR. References: - https://git.kernel.org/stable/c/86ba4f7b9f949e4c4bcb425f2a1ce490fea30df0 - https://git.kernel.org/stable/c/867a4f6cf1a8f511c06e131477988b3b3e7a0633 - https://git.kernel.org/stable/c/35727af2b15d98a2dd2811d631d3a3886111312e
CVE ID: CVE-2023-53384 State: PUBLISHED Published: 2025-09-18T13:33:28.469Z Last Updated: 2025-09-18T13:33:28.469Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: avoid possible NULL skb pointer dereference In 'mwifiex_handle_uap_rx_forward()', always check the value returned by 'skb_copy()' to avoid potential NULL pointer dereference in 'mwifiex_uap_queue_bridged_pkt()', and drop original skb in case of copying failure. Found by Linux Verification Center (linuxtesting.org) with SVACE. References: - https://git.kernel.org/stable/c/d155c5f64cefacdc6a9a26d40be53ee2903c28ff - https://git.kernel.org/stable/c/139d285e7
: - https://git.kernel.org/stable/c/d155c5f64cefacdc6a9a26d40be53ee2903c28ff - https://git.kernel.org/stable/c/139d285e7695279f030dbb172e2d0245425c86c6 - https://git.kernel.org/stable/c/231086e6a36316b823654f4535653f22d6344420 - https://git.kernel.org/stable/c/bef85d58f7709896ed8426560ad117a73a37762f - https://git.kernel.org/stable/c/d7fd24b8d1bb54c5bcf583139e11a5e651e0263c - https://git.kernel.org/stable/c/7e7197e4d6a1bc72a774590d8765909f898be1dc - https://git.kernel.org/stable/c/0c57f9ad2c3ed43abb764b0247d610ff7fdb7a00 - https://git.kernel.org/stable/c/c2509f7c37355e1f0bd5b7087815b845fd383723 - https://git.kernel.org/stable/c/35a7a1ce7c7d61664ee54f5239a1f120ab95a87e
CVE ID: CVE-2023-53385 State: PUBLISHED Published: 2025-09-18T13:33:29.175Z Last Updated: 2025-09-29T10:47:37.027Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: mdp3: Fix resource leaks in of_find_device_by_node Use put_device to release the object get through of_find_device_by_node, avoiding resource leaks. References: - https://git.kernel.org/stable/c/8ba9d91c8f21f070af2049f114c206a8f2d5c71e - https://git.kernel.org/stable/c/fa481125bc4ca8edc1a4c62fe53486ac9a817593 - https://git.kernel.org/stable/c/35ca8ce495366909b4c2e701d1356570dd40c4e2
CVE ID: CVE-2023-53386 State: PUBLISHED Published: 2025-09-18T13:33:29.897Z Last Updated: 2025-09-18T13:33:29.897Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix potential use-after-free when clear keys Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu() call. References: - https://git.kernel.org/stable/c/e87da6a0ac6e631454e7da53a76aa9fe44aaa5dd - https://git.kernel.org/stable/c/942d8cefb022f384d5424f8b90c7878f3f93726f - https://git.kernel.org/stable/c/94617b736c25091b60e514e2e7aeafcbbee6b700 - https://git.kernel.org/stable/c/da1
f93726f - https://git.kernel.org/stable/c/94617b736c25091b60e514e2e7aeafcbbee6b700 - https://git.kernel.org/stable/c/da19f35868dfbecfff4f81166c054d2656cb1be4 - https://git.kernel.org/stable/c/35cc42f04bc49f0656f6840cb7451b3df6049649 - https://git.kernel.org/stable/c/3673952cf0c6cf81b06c66a0b788abeeb02ff3ae
CVE ID: CVE-2023-53387 State: PUBLISHED Published: 2025-09-18T13:33:30.635Z Last Updated: 2025-09-18T13:33:30.635Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix device management cmd timeout flow In the UFS error handling flow, the host will send a device management cmd (NOP OUT) to the device for link recovery. If this cmd times out and clearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing and return. hba->dev_cmd.complete struct is not set to NULL. When this happens, if cmd has been completed by device, then we will call complete() in __ufshcd_transfer_req_compl(). Because the complete s
cmd has been completed by device, then we will call complete() in __ufshcd_transfer_req_compl(). Because the complete struct is allocated on the stack, the following crash will occur: ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync+0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork+0x10/0x30 References: - https://git.
ss_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork+0x10/0x30 References: - https://git.kernel.org/stable/c/cf45493432704786a0f8294c7723ad4eeb5fff24 - https://git.kernel.org/stable/c/3ffd2cd644e0f1eea01339831bac4b1054e8817c - https://git.kernel.org/stable/c/36822124f9de200cedc2f42516301b50d386a6cd
CVE ID: CVE-2023-53388 State: PUBLISHED Published: 2025-09-18T13:33:31.385Z Last Updated: 2025-09-18T13:33:31.385Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Clean dangling pointer on bind error path mtk_drm_bind() can fail, in which case drm_dev_put() is called, destroying the drm_device object. However a pointer to it was still being held in the private object, and that pointer would be passed along to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that point, resulting in a panic. Clean the pointer when destroying the object in the error path to prevent this from happening. References: - https:
nic. Clean the pointer when destroying the object in the error path to prevent this from happening. References: - https://git.kernel.org/stable/c/9a48f99aa7bea15e0b1d8b0040c46b4792eddf3b - https://git.kernel.org/stable/c/a161f1d92aabb3b8463f752bdc3474dc3a5ec0e5 - https://git.kernel.org/stable/c/6a89ddee1686a8872384aaa9f0bcfa6b675acd86 - https://git.kernel.org/stable/c/49cf87919daeeeeeb9e924c39bdd9203af434461 - https://git.kernel.org/stable/c/7b551a501fa714890e55bae73efede1185728d72 - https://git.kernel.org/stable/c/f3887c771576c5d740c5c5b8bf654a8ab8020b7d - https://git.kernel.org/stable/c/36aa8c61af55675ed967900fbe5deb32d776f051
CVE ID: CVE-2023-53389 State: PUBLISHED Published: 2025-09-18T13:33:32.095Z Last Updated: 2025-09-18T13:33:32.095Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: dp: Only trigger DRM HPD events if bridge is attached The MediaTek DisplayPort interface bridge driver starts its interrupts as soon as its probed. However when the interrupts trigger the bridge might not have been attached to a DRM device. As drm_helper_hpd_irq_event() does not check whether the passed in drm_device is valid or not, a NULL pointer passed in results in a kernel NULL pointer dereference in it. Check whether the bridge is attached and only
ULL pointer passed in results in a kernel NULL pointer dereference in it. Check whether the bridge is attached and only trigger an HPD event if it is. References: - https://git.kernel.org/stable/c/6524d3d58797975cc40b85be1e9b89721b4e8d0b - https://git.kernel.org/stable/c/3551789d0635dfb2df8ab8e7fdbf0647e9c1724c - https://git.kernel.org/stable/c/d1c04e338016ae2517c641806a831b1f3eee2bed - https://git.kernel.org/stable/c/36b617f7e4ae663fcadd202ea061ca695ca75539
CVE ID: CVE-2023-53390 State: PUBLISHED Published: 2025-09-18T13:33:32.859Z Last Updated: 2025-09-18T13:33:32.859Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drivers: base: dd: 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/7f1e53f88e8babf293ec052b70aa9d2a3554360c - https://git.kernel.org/stable/c/5a7a9efdb193d3c8a35821548a8e99612c358828 - https://git.kernel.org
052b70aa9d2a3554360c - https://git.kernel.org/stable/c/5a7a9efdb193d3c8a35821548a8e99612c358828 - https://git.kernel.org/stable/c/8e47e2bf78812adbd73c45c941d3c51add30b58d - https://git.kernel.org/stable/c/36c893d3a759ae7c91ee7d4871ebfc7504f08c40
CVE ID: CVE-2023-53391 State: PUBLISHED Published: 2025-09-18T13:33:33.602Z Last Updated: 2025-09-18T13:33:33.602Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfs As the ramfs-based tmpfs uses ramfs_init_fs_context() for the init_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb() to free it and avoid a memory leak. References: - https://git.kernel.org/stable/c/5fada375113767b3b57f1b04f7a4fe64ffaa626f - https://git.kernel.org/stable/c/487f229efea80c00dd7397547ec4f25fb8999d99 - https://git.kernel.org/stable/c/1f34bf8b442c6d720e7fa6f15e8702427e48a
table/c/487f229efea80c00dd7397547ec4f25fb8999d99 - https://git.kernel.org/stable/c/1f34bf8b442c6d720e7fa6f15e8702427e48aea9 - https://git.kernel.org/stable/c/ebe07db840992a3886694ac3d303b06f4b70ce00 - https://git.kernel.org/stable/c/36ce9d76b0a93bae799e27e4f5ac35478c676592
CVE ID: CVE-2023-53392 State: PUBLISHED Published: 2025-09-18T13:33:34.404Z Last Updated: 2025-09-18T13:33:34.404Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix kernel panic during warm reset During warm reset device->fw_client is set to NULL. If a bus driver is registered after this NULL setting and before new firmware clients are enumerated by ISHTP, kernel panic will result in the function ishtp_cl_bus_match(). This is because of reference to device->fw_client->props.protocol_name. ISH firmware after getting successfully loaded, sends a warm reset notification to remove all clients from the bus and s
ISH firmware after getting successfully loaded, sends a warm reset notification to remove all clients from the bus and sets device->fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel module drivers were loaded right after any of the first ISHTP device was registered, regardless of whether it was a matched or an unmatched device. This resulted in all drivers getting registered much before the warm reset notification from ISH. Starting kernel v5.16, this issue got exposed after the change was introduced to load only bus drivers for the respective matching devices. In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are registered after the warm reset device fw_client N
. In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are registered after the warm reset device fw_client NULL setting. cros_ec_ishtp driver_register() triggers the callback to ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel panic in guid_equal() when dereferencing fw_client NULL pointer to get protocol_name. References: - https://git.kernel.org/stable/c/6c8cc40c588f8080a164d88336b1490279e0f1da - https://git.kernel.org/stable/c/45b9055a3a3ff6e8c08faad82ea36a8644a81587 - https://git.kernel.org/stable/c/38518593ec55e897abda4b4be77b2ec8ec4447d1
CVE ID: CVE-2023-53393 State: PUBLISHED Published: 2025-09-18T13:33:35.133Z Last Updated: 2025-09-18T13:33:35.133Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device Currently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0), there is a special handling in order to use the correct counters, but, port_num is being passed down the stack without any change. Also, some functions assume that port_num >=1. As a result, the following oops can occur. BUG: unable to handle page fault for address: ffff89510294f1a8 #PF: supervisor write access in kernel mode #PF: error_cod
UG: unable to handle page fault for address: ffff89510294f1a8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock+0xc/0x20 Call Trace: <TASK> mlx5_ib_get_native_port_mdev+0x73/0xe0 [mlx5_ib] do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib] mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib] ib_setup_device_attrs+0xf0/0x290 [ib_core] ib_register_device+0x3bb/0x510 [ib_core] ? atomic_notifier_chain_register+0x6
ib_setup_device_attrs+0xf0/0x290 [ib_core] ib_register_device+0x3bb/0x510 [ib_core] ? atomic_notifier_chain_register+0x67/0x80 __mlx5_ib_add+0x2b/0x80 [mlx5_ib] mlx5r_probe+0xb8/0x150 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x3c/0x70 ? driver_sysfs_add+0x6b/0x90 really_probe+0xcd/0x380 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 ? driver_allows_async_probing+0x60/0x60 ? driver_allows_async_probing+0x60/0x60 bus_for_each_drv+0x7b/0xc0 __device_attach+0xbc/0x200 bus_probe_device+0x87/0xa0 device_add+0x404/0x940 ? dev_set_name+0x53/0x70 __auxiliary_device_add+0x43/0x60 add_adev+0x99/0xe0 [mlx5_core] mlx5_attach_device+0xc
04/0x940 ? dev_set_name+0x53/0x70 __auxiliary_device_add+0x43/0x60 add_adev+0x99/0xe0 [mlx5_core] mlx5_attach_device+0xc8/0x120 [mlx5_core] mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core] devlink_reload+0x133/0x250 devlink_nl_cmd_reload+0x480/0x570 ? devlink_nl_pre_doit+0x44/0x2b0 genl_family_rcv_msg_doit.isra.0+0xc2/0x110 genl_rcv_msg+0x180/0x2b0 ? devlink_nl_cmd_region_read_dumpit+0x540/0x540 ? devlink_reload+0x250/0x250 ? devlink_put+0x50/0x50 ? genl_family_rcv_msg_doit.isra.0+0x110/0x110 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1f6/0x2c0 netlink_sendmsg+0x237/0x490 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? handle_mm_fault+0x10e/0x290 ? do_user_addr_fault+0x
endmsg+0x237/0x490 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? handle_mm_fault+0x10e/0x290 ? do_user_addr_fault+0x1c0/0x5f0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fix it by setting port_num to 1 in order to get device status and remove unused variable. References: - https://git.kernel.org/stable/c/8d89870d63758363b07ace5c2df82d6bf865f78b - https://git.kernel.org/stable/c/9a97da4674b890b4c28f5f12beba8c33a9cd2f49 - https://git.kernel.org/stable/c/e597b003c736217b0c99ccf1b240c25009105238 - https://git.kernel.org/stable/c/38b50aa44495d5eb4218f0b82fc2da76505cec53
CVE ID: CVE-2023-53394 State: PUBLISHED Published: 2025-09-18T13:33:35.895Z Last Updated: 2025-09-18T13:33:35.895Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix crash on regular rq reactivation When the regular rq is reactivated after the XSK socket is closed it could be reading stale cqes which eventually corrupts the rq. This leads to no more traffic being received on the regular rq and a crash on the next close or deactivation of the rq. Kal Cuttler Conely reported this issue as a crash on the release path when the xdpsock sample program is stopped (killed) and restarted in sequence while traffic is runn
on the release path when the xdpsock sample program is stopped (killed) and restarted in sequence while traffic is running. This patch flushes all cqes when during the rq flush. The cqe flushing is done in the reset state of the rq. mlx5e_rq_to_ready code is moved into the flush function to allow for this. References: - https://git.kernel.org/stable/c/02a84eb2af6bea7871cd34264fb27f141f005fd9 - https://git.kernel.org/stable/c/39646d9bcd1a65d2396328026626859a1dab59d7
CVE ID: CVE-2023-53395 State: PUBLISHED Published: 2025-09-18T13:33:36.624Z Last Updated: 2025-09-18T13:33:36.624Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5 According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode. When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is
d by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed. ============================================================= UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]' CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618
pilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter] References: - https://git.kernel.org/stable/c/2f2a5905303ae230b5159fcd8cdcd5b3e7ad5e2d - https://git.kernel.org/stable/c/23c67fa615c52712bfa02a6dfadbd4656c87c066 - https://git.kernel.org/stable/c/3bf4463e40a17a23f2f261dfd7fe23129bdd04a4 - https://git.kernel.org/stable/c/625c12dc04a607b79f180ef3ee5a12bf2e3324c0 - https://git.kernel.org/stable/c/430787056dd3c591eb553d5c3b2717efc
rg/stable/c/625c12dc04a607b79f180ef3ee5a12bf2e3324c0 - https://git.kernel.org/stable/c/430787056dd3c591eb553d5c3b2717efcf307d4e - https://git.kernel.org/stable/c/e1f686930ee4b059c7baa3c3904b2401829f2589 - https://git.kernel.org/stable/c/b102113469487b460e9e77fe9e00d49c50fe8c86 - https://git.kernel.org/stable/c/3a21ffdbc825e0919db9da0e27ee5ff2cc8a863e
CVE ID: CVE-2023-53396 State: PUBLISHED Published: 2025-09-18T13:33:37.360Z Last Updated: 2025-09-18T13:33:37.360Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix memory leak in do_rename If renaming a file in an encrypted directory, function fscrypt_setup_filename allocates memory for a file name. This name is never used, and before returning to the caller the memory for it is not freed. When running kmemleak on it we see that it is registered as a leak. The report below is triggered by a simple program 'rename' that renames a file in an encrypted directory: unreferenced object 0xffff888101502840 (size 32): comm "ren
gram 'rename' that renames a file in an encrypted directory: unreferenced object 0xffff888101502840 (size 32): comm "rename", pid 9404, jiffies 4302582475 (age 435.735s) backtrace: __kmem_cache_alloc_node __kmalloc fscrypt_setup_filename do_rename ubifs_rename vfs_rename do_renameat2 To fix this we can remove the call to fscrypt_setup_filename as it's not needed. References: - https://git.kernel.org/stable/c/43b2f7d690697182beed6f71aa57b7249d3cfc9c - https://git.kernel.org/stable/c/9f565752b328fe53c9e42b7d4e4d89a1da63d738 - https://git.kernel.org/stable/c/7e264f67b7d6580eff5c2696961039fd05c69258 - https://git.kernel.org/stable/c/517ddc0259d7a7231486bdafde8035c478bc4088 - https://git.kernel.o
5c2696961039fd05c69258 - https://git.kernel.org/stable/c/517ddc0259d7a7231486bdafde8035c478bc4088 - https://git.kernel.org/stable/c/3a36d20e012903f45714df2731261fdefac900cb
CVE ID: CVE-2023-53397 State: PUBLISHED Published: 2025-09-18T13:33:38.093Z Last Updated: 2025-09-18T13:33:38.093Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: modpost: fix off by one in is_executable_section() The > comparison should be >= to prevent an out of bounds array access. References: - https://git.kernel.org/stable/c/7ee557590bac154d324de446d1cd0444988bd511 - https://git.kernel.org/stable/c/02dc8e8bdbe4412cfcf17ee3873e63fa5a55b957 - https://git.kernel.org/stable/c/cb0cdca5c979bc34c27602e2039562932c2591a4 - https://git.kernel.org/stable/c/5e0424cd8a44b5f480feb06753cdf4e1f248d148 - https://git.kernel.org/stable/c/dd87
2591a4 - https://git.kernel.org/stable/c/5e0424cd8a44b5f480feb06753cdf4e1f248d148 - https://git.kernel.org/stable/c/dd872d5576cc94528f427c7264c2c438928cc6d2 - https://git.kernel.org/stable/c/cade370efe2f9e2a79ea8587506ffe2b51ac6d2b - https://git.kernel.org/stable/c/8b2e77050b91199453bf19d0517b047b7339a9e3 - https://git.kernel.org/stable/c/3a3f1e573a105328a2cca45a7cfbebabbf5e3192
CVE ID: CVE-2023-53398 State: PUBLISHED Published: 2025-09-18T13:33:38.842Z Last Updated: 2025-09-18T13:33:38.842Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mlx5: fix possible ptp queue fifo use-after-free Fifo indexes are not checked during pop operations and it leads to potential use-after-free when poping from empty queue. Such case was possible during re-sync action. WARN_ON_ONCE covers future cases. There were out-of-order cqe spotted which lead to drain of the queue and use-after-free because of lack of fifo pointers check. Special check and counter are added to avoid resync operation if SKB could not exist in the fi
k of fifo pointers check. Special check and counter are added to avoid resync operation if SKB could not exist in the fifo because of OOO cqe (skb_id must be between consumer and producer index). References: - https://git.kernel.org/stable/c/52e6e7a0bc04c85012a9251c7cf2d444a77eb966 - https://git.kernel.org/stable/c/6afdedc4e66e3846ce497744f01b95c34bf39d21 - https://git.kernel.org/stable/c/3a50cf1e8e5157b82268eee7e330dbe5736a0948