Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2023-53694 State: PUBLISHED Published: 2025-10-22T13:23:35.869Z Last Updated: 2025-10-22T13:23:35.869Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: ftrace: Fixup panic by disabling preemption In RISCV, we must use an AUIPC + JALR pair to encode an immediate, forming a jump that jumps to an address over 4K. This may cause errors if we want to enable kernel preemption and remove dependency from patching code with stop_machine(). For example, if a task was switched out on auipc. And, if we changed the ftrace function before it was switched back, then it would jump to an address that has updated 11:0 bits mixin
anged the ftrace function before it was switched back, then it would jump to an address that has updated 11:0 bits mixing with previous XLEN:12 part. p: patched area performed by dynamic ftrace ftrace_prologue: p| REG_S ra, -SZREG(sp) p| auipc ra, 0x? ------------> preempted ... change ftrace function ... p| jalr -?(ra) <------------- switched back p| REG_L ra, -SZREG(sp) func: xxx ret References: - https://git.kernel.org/stable/c/84cfcf240f4a577733b1d98fcd2611a611612b03 - https://git.kernel.org/stable/c/20a7510e781084364691b4962de31de758194cc9 - https://git.kernel.org/stable/c/8547649981e6631328cd64f583667501ae385531
CVE ID: CVE-2023-53695 State: PUBLISHED Published: 2025-10-22T13:23:36.524Z Last Updated: 2025-10-22T13:23:36.524Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: udf: Detect system inodes linked into directory hierarchy When UDF filesystem is corrupted, hidden system inodes can be linked into directory hierarchy which is an avenue for further serious corruption of the filesystem and kernel confusion as noticed by syzbot fuzzed images. Refuse to access system inodes linked into directory hierarchy and vice versa. References: - https://git.kernel.org/stable/c/1dc71eeb198a8daa17d0c995998a53b0b749a158 - https://git.kernel.org/stabl
a. References: - https://git.kernel.org/stable/c/1dc71eeb198a8daa17d0c995998a53b0b749a158 - https://git.kernel.org/stable/c/d747b31e2925a2f384e7dd1901a2e5bc5f984ed8 - https://git.kernel.org/stable/c/a44ec34b90440ada190924f5908b97026504fdcd - https://git.kernel.org/stable/c/37e74003d81e79457535cbbdfa1603431c03fac0 - https://git.kernel.org/stable/c/1f328751b65c49c13a312d67a3bf27766b85baf7 - https://git.kernel.org/stable/c/9e3b5ef7d02eaa6553e79b4af9bd99227280f245 - https://git.kernel.org/stable/c/85a37983ec69cc9fcd188bc37c4de15ee326355a
CVE ID: CVE-2023-53696 State: PUBLISHED Published: 2025-10-22T13:23:37.110Z Last Updated: 2025-10-22T13:23:37.110Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in qla2x00_probe_one() There is a memory leak reported by kmemleak: unreferenced object 0xffffc900003f0000 (size 12288): comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110 [<0000000001906886>] __vmalloc_nod
00 ................ backtrace: [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110 [<0000000001906886>] __vmalloc_node+0xbd/0x150 [<000000005bb4dc34>] vmalloc+0x25/0x30 [<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx] [<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx] [<00000000641ccc04>] local_pci_probe+0xeb/0x1a0 The root cause is traced to an error-handling path in qla2x00_probe_one() when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" is used to record the port information and it is allocated in qla2x00_create_host(). However, it is not released in the error handling path "probe_failed". Fix this by freeing the memory of "scan.l" when an e
ever, it is not released in the error handling path "probe_failed". Fix this by freeing the memory of "scan.l" when an error occurs in the adapter initialization process. References: - https://git.kernel.org/stable/c/ae73c4dd48f2c79d515d509a0cbe9efb0a197f44 - https://git.kernel.org/stable/c/44374911ac63f769c442f56fdfadea673c5f4425 - https://git.kernel.org/stable/c/582e35e97318ccd9c81774bac08938291679525f - https://git.kernel.org/stable/c/85ade4010e13ef152ea925c74d94253db92e5428
CVE ID: CVE-2023-53697 State: PUBLISHED Published: 2025-10-22T13:23:37.757Z Last Updated: 2025-10-22T13:23:37.757Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu() Memory pointed by 'nd_pmu->pmu.attr_groups' is allocated in function 'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function 'unregister_nvdimm_pmu'. References: - https://git.kernel.org/stable/c/500a6ff9c2a81348fe0f04e2deb758145e8ab94e - https://git.kernel.org/stable/c/4999f2ec5fde7c45e3ecafda5b78560cc1c7bdb5 - https://git.kernel.org/stable/c/16259c80542ee8945aaa39cfc6a1809bcdc08ffe - h
/4999f2ec5fde7c45e3ecafda5b78560cc1c7bdb5 - https://git.kernel.org/stable/c/16259c80542ee8945aaa39cfc6a1809bcdc08ffe - https://git.kernel.org/stable/c/85ae42c72142346645e63c33835da947dfa008b3
CVE ID: CVE-2023-53698 State: PUBLISHED Published: 2025-10-22T13:23:38.384Z Last Updated: 2025-10-22T13:23:38.384Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xsk: fix refcount underflow in error path Fix a refcount underflow problem reported by syzbot that can happen when a system is running out of memory. If xp_alloc_tx_descs() fails, and it can only fail due to not having enough memory, then the error path is triggered. In this error path, the refcount of the pool is decremented as it has incremented before. However, the reference to the pool in the socket was not nulled. This means that when the socket is closed later, t
ore. However, the reference to the pool in the socket was not nulled. This means that when the socket is closed later, the socket teardown logic will think that there is a pool attached to the socket and try to decrease the refcount again, leading to a refcount underflow. I chose this fix as it involved adding just a single line. Another option would have been to move xp_get_pool() and the assignment of xs->pool to after the if-statement and using xs_umem->pool instead of xs->pool in the whole if-statement resulting in somewhat simpler code, but this would have led to much more churn in the code base perhaps making it harder to backport. References: - https://git.kernel.org/stable/c/789fcd94
more churn in the code base perhaps making it harder to backport. References: - https://git.kernel.org/stable/c/789fcd94c9cac133dd4d96e193188661aca9f6c3 - https://git.kernel.org/stable/c/15b453cf7348973217558235b9ece2ee5fea6777 - https://git.kernel.org/stable/c/3e7722c31d4167eb7f3ffd35aba52cab69b79072 - https://git.kernel.org/stable/c/85c2c79a07302fe68a1ad5cc449458cc559e314d
CVE ID: CVE-2023-53699 State: PUBLISHED Published: 2025-10-22T13:23:38.981Z Last Updated: 2025-10-22T13:23:38.981Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: move memblock_allow_resize() after linear mapping is ready The initial memblock metadata is accessed from kernel image mapping. The regions arrays need to "reallocated" from memblock and accessed through linear mapping to cover more memblock regions. So the resizing should not be allowed until linear mapping is ready. Note that there are memblock allocations when building linear mapping. This patch is similar to 24cc61d8cb5a ("arm64: memblock: don't permit membl
ck allocations when building linear mapping. This patch is similar to 24cc61d8cb5a ("arm64: memblock: don't permit memblock resizing until linear mapping is up"). In following log, many memblock regions are reserved before create_linear_mapping_page_table(). And then it triggered reallocation of memblock.reserved.regions and memcpy the old array in kernel image mapping to the new array in linear mapping which caused a page fault. [ 0.000000] memblock_reserve: [0x00000000bf01f000-0x00000000bf01ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf021000-0x00000000bf021fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x000
0x00000000bf021000-0x00000000bf021fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf023000-0x00000000bf023fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf025000-0x00000000bf025fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf027000-0x00000000bf027fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf029000-0x00000000bf029fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf02b000-0x00000000bf02bfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000
00000bf02b000-0x00000000bf02bfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf02d000-0x00000000bf02dfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf02f000-0x00000000bf02ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf030000-0x00000000bf030fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] OF: reserved mem: 0x0000000080000000..0x000000008007ffff (512 KiB) map non-reusable mmode_resv0@80000000 [ 0.000000] memblock_reserve: [0x00000000bf000000-0x00000000bf001fed] paging_init+0x19a/0x5ae [ 0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 fr
00bf000000-0x00000000bf001fed] paging_init+0x19a/0x5ae [ 0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c [ 0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128 [ 0.000000] memblock: reserved is doubled to 256 at [0x000000017fffd000-0x000000017fffe7ff] [ 0.000000] Unable to handle kernel paging request at virtual address ff600000ffffd000 [ 0.000000] Oops [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.0-rc1-00011-g99a670b2069c #66 [ 0.000000] Hardware name: riscv-virtio,qemu (DT) [ 0.000000] epc : __memcpy+0x
ainted 6.4.0-rc1-00011-g99a670b2069c #66 [ 0.000000] Hardware name: riscv-virtio,qemu (DT) [ 0.000000] epc : __memcpy+0x60/0xf8 [ 0.000000] ra : memblock_double_array+0x192/0x248 [ 0.000000] epc : ffffffff8081d214 ra : ffffffff80a3dfc0 sp : ffffffff81403bd0 [ 0.000000] gp : ffffffff814fbb38 tp : ffffffff8140dac0 t0 : 0000000001600000 [ 0.000000] t1 : 0000000000000000 t2 : 000000008f001000 s0 : ffffffff81403c60 [ 0.000000] s1 : ffffffff80c0bc98 a0 : ff600000ffffd000 a1 : ffffffff80c0bcd8 [ 0.000000] a2 : 0000000000000c00 a3 : ffffffff80c0c8d8 a4 : 0000000080000000 [ 0.000000] a5 : 0000000000080000 a6 : 0000000000000000 a7 : 0000000080200000 [ 0.000000] s2 : ff600000ffffd000 s3 : 0000000000002
] a5 : 0000000000080000 a6 : 0000000000000000 a7 : 0000000080200000 [ 0.000000] s2 : ff600000ffffd000 s3 : 0000000000002000 s4 : 0000000000000c00 [ 0.000000] s5 : ffffffff80c0bc60 s6 : ffffffff80c0bcc8 s7 : 0000000000000000 [ 0.000000] s8 : ffffffff814fd0a8 s9 : 000000017fffe7ff s10: 0000000000000000 [ 0.000000] s11: 0000000000001000 t3 : 0000000000001000 t4 : 0000000000000000 [ 0.000000] t5 : 000000008f003000 t6 : ff600000ffffd000 [ 0.000000] status: 0000000200000100 badaddr: ff600000ffffd000 cause: 000000000000000f [ 0.000000] [<fff ---truncated--- References: - https://git.kernel.org/stable/c/a4284246fca2ef482a8fcf5ad7d2c33a45b41e9c - https://git.kernel.org/stable/c/0a1b80ff4f721c4be98707
it.kernel.org/stable/c/a4284246fca2ef482a8fcf5ad7d2c33a45b41e9c - https://git.kernel.org/stable/c/0a1b80ff4f721c4be98707bfe9d20238df133eb8 - https://git.kernel.org/stable/c/ba11f4e59509538810e5c44578fc73984acdf1d7 - https://git.kernel.org/stable/c/85fadc0d04119c2fe4a20287767ab904c6d21ba1
CVE ID: CVE-2023-53700 State: PUBLISHED Published: 2025-10-22T13:23:39.560Z Last Updated: 2025-10-22T13:23:39.560Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: max9286: Fix memleak in max9286_v4l2_register() There is a kmemleak when testing the media/i2c/max9286.c with bpf mock device: kmemleak: 5 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0xffff88810defc400 (size 256): comm "python3", pid 278, jiffies 4294737563 (age 31.978s) hex dump (first 32 bytes): 28 06 a7 0a 81 88 ff ff 00 fe 22 12 81 88 ff ff (........."..... 10 c4 ef 0d 81 88 ff ff 10 c4 ef 0d 81 88 ff ff ................ b
81 88 ff ff 00 fe 22 12 81 88 ff ff (........."..... 10 c4 ef 0d 81 88 ff ff 10 c4 ef 0d 81 88 ff ff ................ backtrace: [<00000000191de6a7>] __kmalloc_node+0x44/0x1b0 [<000000002f4912b7>] kvmalloc_node+0x34/0x180 [<0000000057dc4cae>] v4l2_ctrl_new+0x325/0x10f0 [videodev] [<0000000026030272>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000f0d9ea2f>] max9286_probe+0x76e/0xbff [max9286] [<00000000ea8f6455>] i2c_device_probe+0x28d/0x680 [<0000000087529af3>] really_probe+0x17c/0x3f0 [<00000000b08be526>] __driver_probe_device+0xe3/0x170 [<000000004382edea>] driver_probe_device+0x49/0x120 [<000000007bde528a>] __device_attach_driver+0xf7/0x150 [<000000009f9c6ab4>] bus_for_each_drv+0x11
robe_device+0x49/0x120 [<000000007bde528a>] __device_attach_driver+0xf7/0x150 [<000000009f9c6ab4>] bus_for_each_drv+0x114/0x180 [<00000000c8aaf588>] __device_attach+0x1e5/0x2d0 [<0000000041cc06b9>] bus_probe_device+0x126/0x140 [<000000002309860d>] device_add+0x810/0x1130 [<000000002827bf98>] i2c_new_client_device+0x359/0x4f0 [<00000000593bdc85>] of_i2c_register_device+0xf1/0x110 max9286_v4l2_register() calls v4l2_ctrl_new_std(), but won't free the created v412_ctrl when fwnode_graph_get_endpoint_by_id() failed, which causes the memleak. Call v4l2_ctrl_handler_free() to free the v412_ctrl. References: - https://git.kernel.org/stable/c/505ff3a0c5951684c3a43094ca4c1a74683d5681 - https://git.ker
the v412_ctrl. References: - https://git.kernel.org/stable/c/505ff3a0c5951684c3a43094ca4c1a74683d5681 - https://git.kernel.org/stable/c/5897fe3ebe8252993579e1bee715ebfe5504e052 - https://git.kernel.org/stable/c/724039e013b34f46344abdbf8c74e6a65a828327 - https://git.kernel.org/stable/c/5e31213fa017c20ccc989033a5f4a626473aa2ca - https://git.kernel.org/stable/c/8636c5fc7658c7c6299fb8b352d24ea4b9ba99e2
CVE ID: CVE-2023-53701 State: REJECTED Published: 2025-10-22T13:23:40.163Z Last Updated: 2025-10-23T05:46:23.597Z Description: No description available.
CVE ID: CVE-2023-53702 State: PUBLISHED Published: 2025-10-22T13:23:40.798Z Last Updated: 2025-10-22T13:23:40.798Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390/crypto: use vector instructions only if available for ChaCha20 Commit 349d03ffd5f6 ("crypto: s390 - add crypto library interface for ChaCha20") added a library interface to the s390 specific ChaCha20 implementation. However no check was added to verify if the required facilities are installed before branching into the assembler code. If compiled into the kernel, this will lead to the following crash, if vector instructions are not available: data exception: 0007 i
into the kernel, this will lead to the following crash, if vector instructions are not available: data exception: 0007 ilc:3 [#1] SMP Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7+ #11 Hardware name: IBM 3931 A01 704 (KVM/Linux) Krnl PSW : 0704e00180000000 000000001857277a (chacha20_vx+0x32/0x818) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000037f0000000a ffffffffffffff60 000000008184b000 0000000019f5c8e6 0000000000000109 0000037fffb13c58 0000037fffb13c78 0000000019bb1780 0000037fffb13c58 0000000019f5c8e6 000000008184b000 0000000000000109 00000000802d8000 0000000000000109 0000000018571ebc 0000037fffb13718 Krnl Code: 000000001857276a: c07
00 0000000000000109 00000000802d8000 0000000000000109 0000000018571ebc 0000037fffb13718 Krnl Code: 000000001857276a: c07000b1f80b larl %r7,0000000019bb1780 0000000018572770: a708000a lhi %r0,10 #0000000018572774: e78950000c36 vlm %v24,%v25,0(%r5),0 >000000001857277a: e7a060000806 vl %v26,0(%r6),0 0000000018572780: e7bf70004c36 vlm %v27,%v31,0(%r7),4 0000000018572786: e70b00000456 vlr %v0,%v27 000000001857278c: e71800000456 vlr %v1,%v24 0000000018572792: e74b00000456 vlr %v4,%v27 Call Trace: [<000000001857277a>] chacha20_vx+0x32/0x818 Last Breaking-Event-Address: [<0000000018571eb6>] chacha20_crypt_s390.constprop.0+0x6e/0xd8 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Att
8571eb6>] chacha20_crypt_s390.constprop.0+0x6e/0xd8 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Fix this by adding a missing MACHINE_HAS_VX check. [agordeev@linux.ibm.com: remove duplicates in commit message] References: - https://git.kernel.org/stable/c/25e8d30507aa2f251152df1af7809e85b5538f4a - https://git.kernel.org/stable/c/debb7797bba0caffdbdadc3e7968bb2c414f50da - https://git.kernel.org/stable/c/8703dd6b238da0ec6c276e53836f8200983d3d9b
CVE ID: CVE-2023-53703 State: PUBLISHED Published: 2025-10-22T13:23:41.450Z Last Updated: 2025-10-22T13:23:41.450Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Fix for shift-out-of-bounds Shift operation of 'exp' and 'shift' variables exceeds the maximum number of shift values in the u32 range leading to UBSAN shift-out-of-bounds. ... [ 6.120512] UBSAN: shift-out-of-bounds in drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c:149:50 [ 6.120598] shift exponent 104 is too large for 64-bit type 'long unsigned int' [ 6.120659] CPU: 4 PID: 96 Comm: kworker/4:1 Not tainted 6.4.0amd_1-next-20230519-dirty #10 [ 6.120665] Har
nsigned int' [ 6.120659] CPU: 4 PID: 96 Comm: kworker/4:1 Not tainted 6.4.0amd_1-next-20230519-dirty #10 [ 6.120665] Hardware name: AMD Birman-PHX/Birman-PHX, BIOS SFH_with_HPD_SEN.FD 04/05/2023 [ 6.120667] Workqueue: events amd_sfh_work_buffer [amd_sfh] [ 6.120687] Call Trace: [ 6.120690] <TASK> [ 6.120694] dump_stack_lvl+0x48/0x70 [ 6.120704] dump_stack+0x10/0x20 [ 6.120707] ubsan_epilogue+0x9/0x40 [ 6.120716] __ubsan_handle_shift_out_of_bounds+0x10f/0x170 [ 6.120720] ? psi_group_change+0x25f/0x4b0 [ 6.120729] float_to_int.cold+0x18/0xba [amd_sfh] [ 6.120739] get_input_rep+0x57/0x340 [amd_sfh] [ 6.120748] ? __schedule+0xba7/0x1b60 [ 6.120756] ? __pfx_get_input_rep+0x10/0x10 [amd_sfh] [ 6.1
p+0x57/0x340 [amd_sfh] [ 6.120748] ? __schedule+0xba7/0x1b60 [ 6.120756] ? __pfx_get_input_rep+0x10/0x10 [amd_sfh] [ 6.120764] amd_sfh_work_buffer+0x91/0x180 [amd_sfh] [ 6.120772] process_one_work+0x229/0x430 [ 6.120780] worker_thread+0x4a/0x3c0 [ 6.120784] ? __pfx_worker_thread+0x10/0x10 [ 6.120788] kthread+0xf7/0x130 [ 6.120792] ? __pfx_kthread+0x10/0x10 [ 6.120795] ret_from_fork+0x29/0x50 [ 6.120804] </TASK> ... Fix this by adding the condition to validate shift ranges. References: - https://git.kernel.org/stable/c/5a45ed1ae34bb0e68944471f4bafb68e0a572791 - https://git.kernel.org/stable/c/1e50bc2c177d4b2953d77037ac46ea0702d6aa1f - https://git.kernel.org/stable/c/87854366176403438d01f368b0
ernel.org/stable/c/1e50bc2c177d4b2953d77037ac46ea0702d6aa1f - https://git.kernel.org/stable/c/87854366176403438d01f368b09de3ec2234e0f5
CVE ID: CVE-2023-53704 State: PUBLISHED Published: 2025-10-22T13:23:42.067Z Last Updated: 2025-10-22T13:23:42.067Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe() Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc() which can automatically release the related memory when the device or driver is removed or unloaded to avoid potential memory leak. In this case, iounmap(anatop_base) in line 427,433 are removed as manual release is not required. Besides, referring to clk-imx8mq.c, check the return code of of_clk_add_hw_provider, if it returns n
se is not required. Besides, referring to clk-imx8mq.c, check the return code of of_clk_add_hw_provider, if it returns negtive, print error info and unregister hws, which makes the program more robust. References: - https://git.kernel.org/stable/c/cb047c13bbf9018693ae31f03a5a26b212d02f13 - https://git.kernel.org/stable/c/bcea444ab4c045864b55d67313833d606676602a - https://git.kernel.org/stable/c/6317d0302655f7e854cd4f31e93b47d35cb058bb - https://git.kernel.org/stable/c/5bcf140e9e6cf76f1f1bd1f489a14ca4d49f9a1a - https://git.kernel.org/stable/c/92ce7629a11ae62292e1cfaa6132dab081fc80ee - https://git.kernel.org/stable/c/878b02d5f3b56cb090dbe2c70c89273be144087f
CVE ID: CVE-2023-53705 State: PUBLISHED Published: 2025-10-22T13:23:42.641Z Last Updated: 2025-10-22T13:23:42.641Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix out-of-bounds access in ipv6_find_tlv() optlen is fetched without checking whether there is more than one byte to parse. It can lead to out-of-bounds access. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. References: - https://git.kernel.org/stable/c/59e656d0d4a84ea0ee9a39c6f69160a3effccc94 - https://git.kernel.org/stable/c/04bf69e3de435d793a203aacc4b774f8f9f2baeb - https://git.kernel.org/stable/c/011f47c8b8389154f996f
git.kernel.org/stable/c/04bf69e3de435d793a203aacc4b774f8f9f2baeb - https://git.kernel.org/stable/c/011f47c8b8389154f996f5f69da8efc3a3beefef - https://git.kernel.org/stable/c/e5f82688ae10f5f386952e65e941bb8868ee54dc - https://git.kernel.org/stable/c/9b92e2d0eb696d7586ba832c8854653b59887da0 - https://git.kernel.org/stable/c/91dd8aab9c9f193210681b86b6b92840ffe74f0c - https://git.kernel.org/stable/c/ae68c0f7edbc9a294094ce03a0aaf45aa489ce40 - https://git.kernel.org/stable/c/878ecb0897f4737a4c9401f3523fd49589025671
CVE ID: CVE-2023-53706 State: PUBLISHED Published: 2025-10-22T13:23:43.228Z Last Updated: 2025-10-22T13:23:43.228Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/vmemmap/devdax: fix kernel crash when probing devdax devices commit 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps") added support for using optimized vmmemap for devdax devices. But how vmemmap mappings are created are architecture specific. For example, powerpc with hash translation doesn't have vmemmap mappings in init_mm page table instead they are bolted table entries in the hardware page table vmemmap_populate_compound_pages() us
init_mm page table instead they are bolted table entries in the hardware page table vmemmap_populate_compound_pages() used by vmemmap optimization code is not aware of these architecture-specific mapping. Hence allow architecture to opt for this feature. I selected architectures supporting HUGETLB_PAGE_OPTIMIZE_VMEMMAP option as also supporting this feature. This patch fixes the below crash on ppc64. BUG: Unable to handle kernel data access on write at 0xc00c000100400038 Faulting instruction address: 0xc000000001269d90 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc5-15