Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
sabled+0xc8/0xd0 localhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx] Use raw_smp_processor_id() instead of smp_processor_id(). Also use queue_work() across the driver instead of queue_work_on() thus avoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled. References: - https://git.kernel.org/stable/c/1a541999f31fcb10ea50eba2a563e6c451fd5c7d - https://git.kernel.org/stable/c/52c7b41ad6ee53222f4ee2f0c099a6ed8291a168 - https://git.kernel.org/stable/c/25bd0c7def04a272f8e89b36971712fe29c6e438 - https://git.kernel.org/stable/c/59f10a05b5c7b675256a66e3161741239889ff80
CVE ID: CVE-2023-53531 State: PUBLISHED Published: 2025-10-01T11:46:15.949Z Last Updated: 2025-10-01T11:46:15.949Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: null_blk: fix poll request timeout handling When doing io_uring benchmark on /dev/nullb0, it's easy to crash the kernel if poll requests timeout triggered, as reported by David. [1] BUG: kernel NULL pointer dereference, address: 0000000000000008 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:null_timeout_rq+0x4e/0x91 Call Trace: ? null_timeout_rq+0x4e/0x91 blk_mq_handle_expired+0x31/0x4b bt_iter+0x68/0x84 ? bt_tags_iter+0x81/0x81 __sbitmap_for_each_set.constprop.0+0x
4e/0x91 blk_mq_handle_expired+0x31/0x4b bt_iter+0x68/0x84 ? bt_tags_iter+0x81/0x81 __sbitmap_for_each_set.constprop.0+0xb0/0xf2 ? __blk_mq_complete_request_remote+0xf/0xf bt_for_each+0x46/0x64 ? __blk_mq_complete_request_remote+0xf/0xf ? percpu_ref_get_many+0xc/0x2a blk_mq_queue_tag_busy_iter+0x14d/0x18e blk_mq_timeout_work+0x95/0x127 process_one_work+0x185/0x263 worker_thread+0x1b5/0x227 This is indeed a race problem between null_timeout_rq() and null_poll(). null_poll() null_timeout_rq() spin_lock(&nq->poll_lock) list_splice_init(&nq->poll_list, &list) spin_unlock(&nq->poll_lock) while (!list_empty(&list)) req = list_first_entry() list_del_init() ... blk_mq_add_to_batch() // req->rq_next =
ll_lock) while (!list_empty(&list)) req = list_first_entry() list_del_init() ... blk_mq_add_to_batch() // req->rq_next = NULL spin_lock(&nq->poll_lock) // rq->queuelist->next == NULL list_del_init(&rq->queuelist) spin_unlock(&nq->poll_lock) Fix these problems by setting requests state to MQ_RQ_COMPLETE under nq->poll_lock protection, in which null_timeout_rq() can safely detect this race and early return. Note this patch just fix the kernel panic when request timeout happen. [1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/ References: - https://git.kernel.org/stable/c/a0b4a0666beacfe8add9c71d8922475541dbae73 - https://git.kernel.org/stable/c/a7cb2e709f2927cc3c76781d
.kernel.org/stable/c/a0b4a0666beacfe8add9c71d8922475541dbae73 - https://git.kernel.org/stable/c/a7cb2e709f2927cc3c76781df3e45de2381b3b9d - https://git.kernel.org/stable/c/5a26e45edb4690d58406178b5a9ea4c6dcf2c105
CVE ID: CVE-2023-53532 State: PUBLISHED Published: 2025-10-01T11:46:16.713Z Last Updated: 2025-10-01T11:46:16.713Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix deinitialization of firmware resources Currently, in ath11k_ahb_fw_resources_init(), iommu domain mapping is done only for the chipsets having fixed firmware memory. Also, for such chipsets, mapping is done only if it does not have TrustZone support. During deinitialization, only if TrustZone support is not there, iommu is unmapped back. However, for non fixed firmware memory chipsets, TrustZone support is not there and this makes the condition check
ack. However, for non fixed firmware memory chipsets, TrustZone support is not there and this makes the condition check to true and it tries to unmap the memory which was not mapped during initialization. This leads to the following trace - [ 83.198790] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 83.259537] Modules linked in: ath11k_ahb ath11k qmi_helpers .. snip .. [ 83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 83.287228] pc : __iommu_unmap+0x30/0x140 [ 83.293907] lr : iommu_unmap+0x5c/0xa4 [ 83.298072] sp : ffff80000b3abad0 .. snip .. [ 83.369175] Call trace: [ 83.376282] __iommu_unmap+0x30/0x140 [ 83.378541] iommu_
072] sp : ffff80000b3abad0 .. snip .. [ 83.369175] Call trace: [ 83.376282] __iommu_unmap+0x30/0x140 [ 83.378541] iommu_unmap+0x5c/0xa4 [ 83.382360] ath11k_ahb_fw_resource_deinit.part.12+0x2c/0xac [ath11k_ahb] [ 83.385666] ath11k_ahb_free_resources+0x140/0x17c [ath11k_ahb] [ 83.392521] ath11k_ahb_shutdown+0x34/0x40 [ath11k_ahb] [ 83.398248] platform_shutdown+0x20/0x2c [ 83.403455] device_shutdown+0x16c/0x1c4 [ 83.407621] kernel_restart_prepare+0x34/0x3c [ 83.411529] kernel_restart+0x14/0x74 [ 83.415781] __do_sys_reboot+0x1c4/0x22c [ 83.419427] __arm64_sys_reboot+0x1c/0x24 [ 83.423420] invoke_syscall+0x44/0xfc [ 83.427326] el0_svc_common.constprop.3+0xac/0xe8 [ 83.430974] do_el0_svc+0xa0/0xa8
83.423420] invoke_syscall+0x44/0xfc [ 83.427326] el0_svc_common.constprop.3+0xac/0xe8 [ 83.430974] do_el0_svc+0xa0/0xa8 [ 83.435659] el0_svc+0x1c/0x44 [ 83.438957] el0t_64_sync_handler+0x60/0x144 [ 83.441910] el0t_64_sync+0x15c/0x160 [ 83.446343] Code: aa0103f4 f9400001 f90027a1 d2800001 (f94006a0) [ 83.449903] ---[ end trace 0000000000000000 ]--- This can be reproduced by probing an AHB chipset which is not having a fixed memory region. During reboot (or rmmod) trace can be seen. Fix this issue by adding a condition check on firmware fixed memory hw_param as done in the counter initialization function. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 References: - ht
ounter initialization function. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 References: - https://git.kernel.org/stable/c/0324300dce3412d4737b4ec5898d0188495a7caa - https://git.kernel.org/stable/c/8faf862d81ab197757761e87d0a99fbb96ab2cf0 - https://git.kernel.org/stable/c/a1548363582a8066edd4986f839d785f13dda3aa - https://git.kernel.org/stable/c/5a78ac33e3cb8822da64dd1af196e83664b332b0
CVE ID: CVE-2023-53533 State: PUBLISHED Published: 2025-10-04T15:16:45.207Z Last Updated: 2025-10-04T15:16:45.207Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Input: raspberrypi-ts - fix refcount leak in rpi_ts_probe rpi_firmware_get() take reference, we need to release it in error paths as well. Use devm_rpi_firmware_get() helper to handling the resources. Also remove the existing rpi_firmware_put(). References: - https://git.kernel.org/stable/c/1dfa3c9dd27bdc347733d06e980395768520bc3e - https://git.kernel.org/stable/c/0d6a5c9489c8a3d434e685066119c4333476dccd - https://git.kernel.org/stable/c/7acad58049acc6ac148e8b613a6ecee
.org/stable/c/0d6a5c9489c8a3d434e685066119c4333476dccd - https://git.kernel.org/stable/c/7acad58049acc6ac148e8b613a6eceeca4bcb4a7 - https://git.kernel.org/stable/c/36d087e49dabd28d2c13a7532dac72d625ce69fb - https://git.kernel.org/stable/c/9dbbe9db224c23a60dc7b1e00c701be93328c873 - https://git.kernel.org/stable/c/9216aa5cfd86809a2681be3683cd9ac30432de0c - https://git.kernel.org/stable/c/5bca3688bdbc3b58a2894b8671a8e2378efe28bd
CVE ID: CVE-2023-53534 State: PUBLISHED Published: 2025-10-04T15:16:45.909Z Last Updated: 2025-10-04T15:16:45.909Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: mtk_drm_crtc: Add checks for devm_kcalloc As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference. References: - https://git.kernel.org/stable/c/b64b6dff15a38468b8cd33fc7864fa4e02b0933a - https://git.kernel.org/stable/c/62952905e195f7350bc230cf0960a74ddbceed5d - https://git.kernel.org/stable/c/67ea657c7891c2f86a7750395640d9bdf2555926 - https://git.kernel.org/stable/c/7d569ae98ee5490585929be69fea68047679
stable/c/67ea657c7891c2f86a7750395640d9bdf2555926 - https://git.kernel.org/stable/c/7d569ae98ee5490585929be69fea68047679b7b2 - https://git.kernel.org/stable/c/5bf1e3bd7da625ccf9a22c8cb7d65271e6e47f4c
CVE ID: CVE-2023-53535 State: PUBLISHED Published: 2025-10-04T15:16:46.583Z Last Updated: 2025-10-04T15:16:46.583Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Add a check for oversized packets Occasionnaly we may get oversized packets from the hardware which exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early check which drops the packet to avoid invoking skb_over_panic() and move on to processing the next packet. References: - https://git.kernel.org/stable/c/7cdb07e10c1258c08f31b24898930e4ece88d163 - https://git.kernel.org/stable/c/c34b1c0870323649d45c5074828d7f754dea2673 - https://git.ker
8c08f31b24898930e4ece88d163 - https://git.kernel.org/stable/c/c34b1c0870323649d45c5074828d7f754dea2673 - https://git.kernel.org/stable/c/87363d1ab55e497702a9506ff423c422639c8a25 - https://git.kernel.org/stable/c/841881320562cbeac7046b537b91cd000480cea2 - https://git.kernel.org/stable/c/124ca24e0de958d2e20e0aa1e2434af7b72f8887 - https://git.kernel.org/stable/c/5f56767fb5f2df875b6553e08dbec6a45431c988 - https://git.kernel.org/stable/c/411317d2a4a7d6049d8efeef0d32ae43f8baefce - https://git.kernel.org/stable/c/5c0862c2c962052ed5055220a00ac1cefb92fbcd
CVE ID: CVE-2023-53536 State: PUBLISHED Published: 2025-10-04T15:16:47.304Z Last Updated: 2025-10-04T15:16:47.304Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: blk-crypto: make blk_crypto_evict_key() more robust If blk_crypto_evict_key() sees that the key is still in-use (due to a bug) or that ->keyslot_evict failed, it currently just returns while leaving the key linked into the keyslot management structures. However, blk_crypto_evict_key() is only called in contexts such as inode eviction where failure is not an option. So actually the caller proceeds with freeing the blk_crypto_key regardless of the return value of blk_cry
not an option. So actually the caller proceeds with freeing the blk_crypto_key regardless of the return value of blk_crypto_evict_key(). These two assumptions don't match, and the result is that there can be a use-after-free in blk_crypto_reprogram_all_keys() after one of these errors occurs. (Note, these errors *shouldn't* happen; we're just talking about what happens if they do anyway.) Fix this by making blk_crypto_evict_key() unlink the key from the keyslot management structures even on failure. Also improve some comments. References: - https://git.kernel.org/stable/c/701a8220762ff90615dc91d3543f789391b63298 - https://git.kernel.org/stable/c/5bb4005fb667c6e2188fa87950f8d5faf2994410 - htt
01a8220762ff90615dc91d3543f789391b63298 - https://git.kernel.org/stable/c/5bb4005fb667c6e2188fa87950f8d5faf2994410 - https://git.kernel.org/stable/c/64ef787bb1588475163069c2e62fdd8f6c27b1f6 - https://git.kernel.org/stable/c/809a5be62e92a444a3c3d7b9f438019d0b322f55 - https://git.kernel.org/stable/c/5c62852942667c613de0458fc797c5b8c36112b5 - https://git.kernel.org/stable/c/5c7cb94452901a93e90c2230632e2c12a681bc92
CVE ID: CVE-2023-53537 State: PUBLISHED Published: 2025-10-04T15:16:48.006Z Last Updated: 2025-10-04T15:16:48.006Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free for cached IPU bio xfstest generic/019 reports a bug: kernel BUG at mm/filemap.c:1619! RIP: 0010:folio_end_writeback+0x8a/0x90 Call Trace: end_page_writeback+0x1c/0x60 f2fs_write_end_io+0x199/0x420 bio_endio+0x104/0x180 submit_bio_noacct+0xa5/0x510 submit_bio+0x48/0x80 f2fs_submit_write_bio+0x35/0x300 f2fs_submit_merged_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_page
ed_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_pages+0x30c/0x340 do_writepages+0xd8/0x1b0 __writeback_single_inode+0x44/0x370 writeback_sb_inodes+0x233/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x2d0 wb_workfn+0x367/0x4a0 process_one_work+0x21d/0x430 worker_thread+0x4e/0x3c0 kthread+0x103/0x130 ret_from_fork+0x2c/0x50 The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write() in f2fs_write_single_data_page() tries to flush IPU bio in cache, however f2fs_submit_merged_ipu_write() missed to check validity of @bio parameter, result in submitting random cached bio which belong to other IO context, t
) missed to check validity of @bio parameter, result in submitting random cached bio which belong to other IO context, then it will cause use-after-free issue, fix it by adding additional validity check. References: - https://git.kernel.org/stable/c/b2f423fda64fb49213aa0ed5056079cf295a5df2 - https://git.kernel.org/stable/c/9a7f63283af6befc0f91d549f4f6917dff7479a9 - https://git.kernel.org/stable/c/7d058f0ab161437369ad6e45a4b67c2886e71373 - https://git.kernel.org/stable/c/97ec6f1788cc6bee3f8c89cb908e1a2a1cd859bb - https://git.kernel.org/stable/c/af4ce124d7bd74cb839bbdaccffbb416771a56b5 - https://git.kernel.org/stable/c/5cdb422c839134273866208dad5360835ddb9794
CVE ID: CVE-2023-53538 State: PUBLISHED Published: 2025-10-04T15:16:48.694Z Last Updated: 2025-10-04T15:16:48.694Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: insert tree mod log move in push_node_left There is a fairly unlikely race condition in tree mod log rewind that can result in a kernel panic which has the following trace: [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002 [530.618] #PF: supervisor read access in kernel mode [530.629] #P
el NULL pointer dereference, address: 0000000000000002 [530.618] #PF: supervisor read access in kernel mode [530.629] #PF: error_code(0x0000) - not-present page [530.641] PGD 0 P4D 0 [530.647] Oops: 0000 [#1] SMP [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S O K 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1 [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017 [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00 [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246 [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8 [530.800
f888292e41000 RCX: f2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8 [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000 [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0 [530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000 [530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0 [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000
000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [530.928] Call Trace: [530.934] ? btrfs_printk+0x13b/0x18c [530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130 [530.955] btrfs_map_bio+0x75/0x330 [530.963] ? kmem_cache_alloc+0x12a/0x2d0 [530.973] ? btrfs_submit_metadata_bio+0x63/0x100 [530.984] btrfs_submit_metadata_bio+0xa4/0x100 [530.995] submit_extent_page+0x30f/0x360 [531.004] read_extent_buffer_pages+0x49e/0x6d0 [531.015] ? submit_extent_page+0x360/0x360 [531.025] btree_read_extent_buffer_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_sear
er_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_search_old_slot+0x198/0x2f0 [531.066] resolve_indirect_ref+0xfe/0x6f0 [531.076] ? ulist_alloc+0x31/0x60 [531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0 [531.095] find_parent_nodes+0x720/0x1830 [531.105] ? ulist_alloc+0x10/0x60 [531.113] iterate_extent_inodes+0xea/0x370 [531.123] ? btrfs_previous_extent_item+0x8f/0x110 [531.134] ? btrfs_search_path_in_tree+0x240/0x240 [531.146] iterate_inodes_from_logical+0x98/0xd0 [531.157] ? btrfs_search_path_in_tree+0x240/0x240 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0 This occurs when logical inode reso
40 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0 This occurs when logical inode resolution takes a tree mod log sequence number, and then while backref walking hits a rewind on a busy node which has the following sequence of tree mod log operations (numbers filled in from a specific example, but they are somewhat arbitrary) REMOVE_WHILE_FREEING slot 532 REMOVE_WHILE_FREEING slot 531 REMOVE_WHILE_FREEING slot 530 ... REMOVE_WHILE_FREEING slot 0 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 ADD slot 455 ADD slot 454 ADD slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ...
slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 When this sequence gets applied via btrfs_tree_mod_log_rewind, it allocates a fresh rewind eb, and first inserts the correct key info for the 533 elements, then overwrites the first 456 of them, then decrements the count by 456 via the add ops, then rewinds the move by doing a memmove from 456:988->0:532. We have never written anything past 532, ---truncated--- References: - https://git.kernel.org/stable/c/11f14402fe3437852cb44945b3b9f1bdb4032956 - https://git.kernel.org/stable/c/5cead5422a0e3d13b0bcee986c0f5c4ebb94100b
CVE ID: CVE-2023-53539 State: PUBLISHED Published: 2025-10-04T15:16:49.379Z Last Updated: 2025-10-04T15:16:49.379Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix incomplete state save in rxe_requester If a send packet is dropped by the IP layer in rxe_requester() the call to rxe_xmit_packet() can fail with err == -EAGAIN. To recover, the state of the wqe is restored to the state before the packet was sent so it can be resent. However, the routines that save and restore the state miss a significnt part of the variable state in the wqe, the dma struct which is used to process through the sge table. And, the state is
part of the variable state in the wqe, the dma struct which is used to process through the sge table. And, the state is not saved before the packet is built which modifies the dma struct. Under heavy stress testing with many QPs on a fast node sending large messages to a slow node dropped packets are observed and the resent packets are corrupted because the dma struct was not restored. This patch fixes this behavior and allows the test cases to succeed. References: - https://git.kernel.org/stable/c/70518f3aaf5a059b691867d7d2d46b999319656a - https://git.kernel.org/stable/c/2f2a6422287fe29f9343247d77b645100ece0652 - https://git.kernel.org/stable/c/255c0e60e1d16874fc151358d94bc8df661600dd - ht
2f2a6422287fe29f9343247d77b645100ece0652 - https://git.kernel.org/stable/c/255c0e60e1d16874fc151358d94bc8df661600dd - https://git.kernel.org/stable/c/5d122db2ff80cd2aed4dcd630befb56b51ddf947
CVE ID: CVE-2023-53540 State: PUBLISHED Published: 2025-10-04T15:16:50.079Z Last Updated: 2025-10-04T15:16:50.079Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: reject auth/assoc to AP with our address If the AP uses our own address as its MLD address or BSSID, then clearly something's wrong. Reject such connections so we don't try and fail later. References: - https://git.kernel.org/stable/c/676a423410131d111a264d29aecbe6aadd57fb22 - https://git.kernel.org/stable/c/07added2c6cd63de047bc786b39436322abb67c0 - https://git.kernel.org/stable/c/5d4e04bf3a0f098bd9033de3a5291810fa14c7a6
CVE ID: CVE-2023-53541 State: PUBLISHED Published: 2025-10-04T15:16:50.765Z Last Updated: 2025-10-04T15:16:50.765Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write When the oob buffer length is not in multiple of words, the oob write function does out-of-bounds read on the oob source buffer at the last iteration. Fix that by always checking length limit on the oob buffer read and fill with 0xff when reaching the end of the buffer to the oob registers. References: - https://git.kernel.org/stable/c/2bc3d6ac704ea7263175ea3da663fdbbb7f3dd8b - https://git.kernel.o
registers. References: - https://git.kernel.org/stable/c/2bc3d6ac704ea7263175ea3da663fdbbb7f3dd8b - https://git.kernel.org/stable/c/14b1d00520b4d6a4818364334ce472b79cfc8976 - https://git.kernel.org/stable/c/aae45746f4aee9818296e0500e0703e9d8caa5b8 - https://git.kernel.org/stable/c/d00b031266514a9395124704630b056a5185ec17 - https://git.kernel.org/stable/c/2353b7bb61e45e7cfd21505d0c6747ac8c9496a1 - https://git.kernel.org/stable/c/45fe4ad7f439799ee1b7b5f80bf82e8b34a98d25 - https://git.kernel.org/stable/c/648d1150a688698e37f7aaf302860180901cb30e - https://git.kernel.org/stable/c/5d53244186c9ac58cb88d76a0958ca55b83a15cd
CVE ID: CVE-2023-53542 State: PUBLISHED Published: 2025-10-04T15:16:51.440Z Last Updated: 2025-10-04T15:16:51.440Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phy For some reason, the driver adding support for Exynos5420 MIPI phy back in 2016 wasn't used on Exynos5420, which caused a kernel panic. Add the proper compatible for it. References: - https://git.kernel.org/stable/c/c075aa3467a799855a92289a3c619afc0a2ad193 - https://git.kernel.org/stable/c/537bdfc1a67836fbd68bbe4210bc380f72cca47f - https://git.kernel.org/stable/c/f10001af0f7246cf3e43530d25f8d59a8db10df6
le/c/537bdfc1a67836fbd68bbe4210bc380f72cca47f - https://git.kernel.org/stable/c/f10001af0f7246cf3e43530d25f8d59a8db10df6 - https://git.kernel.org/stable/c/199624f3144d79fab1cff533ce6a4b82390520a3 - https://git.kernel.org/stable/c/2e68a0f7bc576318a58335c31c542b358bc63f83 - https://git.kernel.org/stable/c/f2a6198f5ed7d6e4e06d87a4de007f2e45cc9583 - https://git.kernel.org/stable/c/29961ee63dd676cc67f7c00f76faa21e11f0d7c6 - https://git.kernel.org/stable/c/5d5aa219a790d61cad2c38e1aa32058f16ad2f0b
CVE ID: CVE-2023-53543 State: PUBLISHED Published: 2025-10-04T15:16:52.114Z Last Updated: 2025-10-04T15:16:52.114Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missin
y lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa max vqp attr to avoid such bugs. References: - https://git.kernel.org/stable/c/ff71709445ac033e6e250d971683110e4781c068 - https://git.kernel.org/stable/c/ea65e8b5e6b1a34deda7564f09c90e9e80db436a - https://git.kernel.org/stable/c/5d6ba607d6cb5c58a4ddf33381e18c83dbb4098f