Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2023-53317 State: PUBLISHED Published: 2025-09-16T16:11:53.877Z Last Updated: 2025-09-16T16:11:53.877Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix WARNING in mb_find_extent Syzbot found the following issue: EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support! EXT4-fs (loop0): orphan cleanup on readonly fs ------------[ cut here ]------------ WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30 Modules linked in: CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google G
e30 Modules linked in: CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869 RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293 RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0 RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040 RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402 R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000 R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc FS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS:
: dffffc0000000000 R15: ffffc90003c9e2cc FS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307 ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735 ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605 ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286 ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651 ext4_getblk+0x1b9/0x770 fs/ext
cks+0x1868/0x6880 fs/ext4/extents.c:4286 ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651 ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864 ext4_bread+0x2a/0x170 fs/ext4/inode.c:920 ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105 write_blk fs/quota/quota_tree.c:64 [inline] get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130 do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375 dq_insert_tree fs/quota/quota_tree.c:401 [inline] qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420 v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358 dquo
[inline] qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420 v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358 dquot_acquire+0x348/0x670 fs/quota/dquot.c:444 ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740 dqget+0x999/0xdc0 fs/quota/dquot.c:914 __dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492 ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c:5516 [inline] ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/names
/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Add some debug information: mb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/1@3735929054 64 64 7 block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Acctually, blocks per group is 64, but block bitmap indicate at least has 128 blocks. Now, ext4_validate_block_bitmap() didn't check inv
s per group is 64, but block bitmap indicate at least has 128 blocks. Now, ext4_validate_block_bitmap() didn't check invalid block's bitmap if set. To resolve above issue, add check like fsck "Padding at end of block bitmap is not set". References: - https://git.kernel.org/stable/c/775b00ba23f6f916fe2ac60c5ff7fd0fe4f28d0d - https://git.kernel.org/stable/c/1b90fbc7590124c57a2e590de7fd07eba26606f1 - https://git.kernel.org/stable/c/5d356d902e9d5b1aaaaf2326d365340fa8a90c1b - https://git.kernel.org/stable/c/d55e76e11592a1d18a179c7fd34ca1b52632beb3 - https://git.kernel.org/stable/c/dba62fa84a8eac44a53a2862de8a40e5bdfa0ae3 - https://git.kernel.org/stable/c/e4d503c956a744cb59e509ca5f134cfad423c7a3 -
/c/dba62fa84a8eac44a53a2862de8a40e5bdfa0ae3 - https://git.kernel.org/stable/c/e4d503c956a744cb59e509ca5f134cfad423c7a3 - https://git.kernel.org/stable/c/dd45e536f47a82e0a405f9a4b6c7ceb367171ee9 - https://git.kernel.org/stable/c/fa08a7b61dff8a4df11ff1e84abfc214b487caf7
CVE ID: CVE-2023-53318 State: PUBLISHED Published: 2025-09-16T16:11:54.677Z Last Updated: 2025-09-16T16:11:54.677Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: recordmcount: Fix memory leaks in the uwrite function Common realloc mistake: 'file_append' nulled but not freed upon failure References: - https://git.kernel.org/stable/c/bd39f68a309a947670379bf9a39b16c584f86ddb - https://git.kernel.org/stable/c/444ec005404cead222ebce2561a9451c9ee5ad89 - https://git.kernel.org/stable/c/3ed95a6f6c646e8bb15c354536e0ab10e8f39c08 - https://git.kernel.org/stable/c/2d9ca5f62f2ba160ff9c9be4adf401c46c04edef - https://git.kernel.org/stable/c/f
0e8f39c08 - https://git.kernel.org/stable/c/2d9ca5f62f2ba160ff9c9be4adf401c46c04edef - https://git.kernel.org/stable/c/ff70ad9159fbb566b2c15724f44207e8deccd527 - https://git.kernel.org/stable/c/895130e63c93926f07caf5db286b97bd27b81de9 - https://git.kernel.org/stable/c/25c9b185f121812cbc215fdaa1192c6b9025b428 - https://git.kernel.org/stable/c/fa359d068574d29e7d2f0fdd0ebe4c6a12b5cfb9
CVE ID: CVE-2023-53319 State: PUBLISHED Published: 2025-09-16T16:11:55.490Z Last Updated: 2025-09-16T16:11:55.490Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Handle kvm_arm_init failure correctly in finalize_pkvm Currently there is no synchronisation between finalize_pkvm() and kvm_arm_init() initcalls. The finalize_pkvm() proceeds happily even if kvm_arm_init() fails resulting in the following warning on all the CPUs and eventually a HYP panic: | kvm [1]: IPA Size Limit: 48 bits | kvm [1]: Failed to init hyp memory protection | kvm [1]: error initializing Hyp mode: -22 | | <snip> | | WARNING: CPU: 0 PID: 0 at a
led to init hyp memory protection | kvm [1]: error initializing Hyp mode: -22 | | <snip> | | WARNING: CPU: 0 PID: 0 at arch/arm64/kvm/pkvm.c:226 _kvm_host_prot_finalize+0x30/0x50 | Modules linked in: | CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0 #237 | Hardware name: FVP Base RevC (DT) | pstate: 634020c5 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : _kvm_host_prot_finalize+0x30/0x50 | lr : __flush_smp_call_function_queue+0xd8/0x230 | | Call trace: | _kvm_host_prot_finalize+0x3c/0x50 | on_each_cpu_cond_mask+0x3c/0x6c | pkvm_drop_host_privileges+0x4c/0x78 | finalize_pkvm+0x3c/0x5c | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0
ze_pkvm+0x3c/0x5c | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x100/0x16c | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 | Failed to finalize Hyp protection: -22 | dtb=fvp-base-revc.dtb | kvm [95]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:540! | kvm [95]: nVHE call trace: | kvm [95]: [<ffff800081052984>] __kvm_nvhe_hyp_panic+0xac/0xf8 | kvm [95]: [<ffff800081059644>] __kvm_nvhe_handle_host_mem_abort+0x1a0/0x2ac | kvm [95]: [<ffff80008105511c>] __kvm_nvhe_handle_trap+0x4c/0x160 | kvm [95]: [<ffff8000810540fc>] __kvm_nvhe___skip_pauth_save+0x4/0x4 | kvm [95]: ---[ end nVHE call trace ]--
x4c/0x160 | kvm [95]: [<ffff8000810540fc>] __kvm_nvhe___skip_pauth_save+0x4/0x4 | kvm [95]: ---[ end nVHE call trace ]--- | kvm [95]: Hyp Offset: 0xfffe8db00ffa0000 | Kernel panic - not syncing: HYP panic: | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800 | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000 | VCPU:0000000000000000 | CPU: 3 PID: 95 Comm: kworker/u16:2 Tainted: G W 6.4.0 #237 | Hardware name: FVP Base RevC (DT) | Workqueue: rpciod rpc_async_schedule | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x138/0x33c | nvhe_hyp_panic_handler+0x100/0x184 | new_slab+0x23c/0x54c | ___slab_alloc+0
| dump_stack+0x18/0x24 | panic+0x138/0x33c | nvhe_hyp_panic_handler+0x100/0x184 | new_slab+0x23c/0x54c | ___slab_alloc+0x3e4/0x770 | kmem_cache_alloc_node+0x1f0/0x278 | __alloc_skb+0xdc/0x294 | tcp_stream_alloc_skb+0x2c/0xf0 | tcp_sendmsg_locked+0x3d0/0xda4 | tcp_sendmsg+0x38/0x5c | inet_sendmsg+0x44/0x60 | sock_sendmsg+0x1c/0x34 | xprt_sock_sendmsg+0xdc/0x274 | xs_tcp_send_request+0x1ac/0x28c | xprt_transmit+0xcc/0x300 | call_transmit+0x78/0x90 | __rpc_execute+0x114/0x3d8 | rpc_async_schedule+0x28/0x48 | process_one_work+0x1d8/0x314 | worker_thread+0x248/0x474 | kthread+0xfc/0x184 | ret_from_fork+0x10/0x20 | SMP: stopping secondary CPUs | Kernel Offset: 0x57c5cb460000 from 0xffff80008000000
fc/0x184 | ret_from_fork+0x10/0x20 | SMP: stopping secondary CPUs | Kernel Offset: 0x57c5cb460000 from 0xffff800080000000 | PHYS_OFFSET: 0x80000000 | CPU features: 0x00000000,1035b7a3,ccfe773f | Memory Limit: none | ---[ end Kernel panic - not syncing: HYP panic: | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800 | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000 | VCPU:0000000000000000 ]--- Fix it by checking for the successfull initialisation of kvm_arm_init() in finalize_pkvm() before proceeding any futher. References: - https://git.kernel.org/stable/c/91450dec0445f4d12f960ba68d8d05c3cb2ab5b8 - https://git.kernel.org/stable/c/fa729bc7c9c8c17a2481358c841ef8ca920485d3
CVE ID: CVE-2023-53320 State: PUBLISHED Published: 2025-09-16T16:11:56.323Z Last Updated: 2025-09-16T16:11:56.323Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() The function mpi3mr_get_all_tgt_info() has four issues: 1) It calculates valid entry length in alltgt_info assuming the header part of the struct mpi3mr_device_map_info would equal to sizeof(u32). The correct size is sizeof(u64). 2) When it calculates the valid entry length kern_entrylen, it excludes one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4)
es one entry by subtracting 1 from num_devices. 3) It copies num_device by calling memcpy(). Substitution is enough. 4) It does not specify the calculated length to sg_copy_from_buffer(). Instead, it specifies the payload length which is larger than the alltgt_info size. It causes "BUG: KASAN: slab-out-of-bounds". Fix the issues by using the correct header size, removing the subtraction from num_devices, replacing the memcpy() with substitution and specifying the correct length to sg_copy_from_buffer(). References: - https://git.kernel.org/stable/c/8ba997b22f2cd5d29aad8c39f6201f7608ed0c04 - https://git.kernel.org/stable/c/2f3d3fa5b8ed7d3b147478f42b00b468eeb1ecd2 - https://git.kernel.org/stab
6201f7608ed0c04 - https://git.kernel.org/stable/c/2f3d3fa5b8ed7d3b147478f42b00b468eeb1ecd2 - https://git.kernel.org/stable/c/fb428a2005fc1260d18b989cc5199f281617f44d
CVE ID: CVE-2023-53321 State: PUBLISHED Published: 2025-09-16T16:11:57.206Z Last Updated: 2025-09-16T16:11:57.206Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: drop short frames While technically some control frames like ACK are shorter and end after Address 1, such frames shouldn't be forwarded through wmediumd or similar userspace, so require the full 3-address header to avoid accessing invalid memory if shorter frames are passed in. References: - https://git.kernel.org/stable/c/3beb97bed860d95b14ad23578ce8ddaea62023db - https://git.kernel.org/stable/c/672205c6f2d11978fcd7f0f336bb2c708e28874b - https:/
7bed860d95b14ad23578ce8ddaea62023db - https://git.kernel.org/stable/c/672205c6f2d11978fcd7f0f336bb2c708e28874b - https://git.kernel.org/stable/c/c64ee9dd335832d5e2ab0a8fc83a34ad4c729799 - https://git.kernel.org/stable/c/b9a175e3b250b0dc6e152988040aa5014e98e61e - https://git.kernel.org/stable/c/89a41ed7f21476301659ebd25ccb48a60791c1a7 - https://git.kernel.org/stable/c/fba360a047d5eeeb9d4b7c3a9b1c8308980ce9a6
CVE ID: CVE-2023-53322 State: PUBLISHED Published: 2025-09-16T16:11:58.062Z Last Updated: 2025-09-16T16:11:58.062Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Wait for io return on terminate rport System crash due to use after free. Current code allows terminate_rport_io to exit before making sure all IOs has returned. For FCP-2 device, IO's can hang on in HW because driver has not tear down the session in FW at first sign of cable pull. When dev_loss_tmo timer pops, terminate_rport_io is called and upper layer is about to free various resources. Terminate_rport_io trigger qla to do the final cleanup, but the
led and upper layer is about to free various resources. Terminate_rport_io trigger qla to do the final cleanup, but the cleanup might not be fast enough where it leave qla still holding on to the same resource. Wait for IO's to return to upper layer before resources are freed. References: - https://git.kernel.org/stable/c/8a55556cd7e0220486163b1285ce11a8be2ce5fa - https://git.kernel.org/stable/c/4647d2e88918a078359d1532d90c417a38542c9e - https://git.kernel.org/stable/c/d25fded78d88e1515439b3ba581684d683e0b6ab - https://git.kernel.org/stable/c/a9fe97fb7b4ee21bffb76f2acb05769bad27ae70 - https://git.kernel.org/stable/c/079c8264ed9fea8cbcac01ad29040f901cbc3692 - https://git.kernel.org/stable/c/9
bad27ae70 - https://git.kernel.org/stable/c/079c8264ed9fea8cbcac01ad29040f901cbc3692 - https://git.kernel.org/stable/c/90770dad1eb30967ebd8d37d82830bcf270b3293 - https://git.kernel.org/stable/c/5bcdaafd92be6035ddc77fa76650cf9dd5b864c4 - https://git.kernel.org/stable/c/fc0cba0c7be8261a1625098bd1d695077ec621c9
CVE ID: CVE-2023-53323 State: PUBLISHED Published: 2025-09-16T16:11:58.877Z Last Updated: 2025-09-16T16:11:58.877Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext2/dax: Fix ext2_setsize when len is page aligned PAGE_ALIGN(x) macro gives the next highest value which is multiple of pagesize. But if x is already page aligned then it simply returns x. So, if x passed is 0 in dax_zero_range() function, that means the length gets passed as 0 to ->iomap_begin(). In ext2 it then calls ext2_get_blocks -> max_blocks as 0 and hits bug_on here in ext2_get_blocks(). BUG_ON(maxblocks == 0); Instead we should be calling dax_truncate_page()
as 0 and hits bug_on here in ext2_get_blocks(). BUG_ON(maxblocks == 0); Instead we should be calling dax_truncate_page() here which takes care of it. i.e. it only calls dax_zero_range if the offset is not page/block aligned. This can be easily triggered with following on fsdax mounted pmem device. dd if=/dev/zero of=file count=1 bs=512 truncate -s 0 file [79.525838] EXT2-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk [79.529376] ext2 filesystem being mounted at /mnt1/test supports timestamps until 2038 (0x7fffffff) [93.793207] ------------[ cut here ]------------ [93.795102] kernel BUG at fs/ext2/inode.c:637! [93.796904] invalid opcode: 0000 [#1] PREEMPT SMP PTI [93.798
----------- [93.795102] kernel BUG at fs/ext2/inode.c:637! [93.796904] invalid opcode: 0000 [#1] PREEMPT SMP PTI [93.798659] CPU: 0 PID: 1192 Comm: truncate Not tainted 6.3.0-rc2-xfstests-00056-g131086faa369 #139 [93.806459] RIP: 0010:ext2_get_blocks.constprop.0+0x524/0x610 <...> [93.835298] Call Trace: [93.836253] <TASK> [93.837103] ? lock_acquire+0xf8/0x110 [93.838479] ? d_lookup+0x69/0xd0 [93.839779] ext2_iomap_begin+0xa7/0x1c0 [93.841154] iomap_iter+0xc7/0x150 [93.842425] dax_zero_range+0x6e/0xa0 [93.843813] ext2_setsize+0x176/0x1b0 [93.845164] ext2_setattr+0x151/0x200 [93.846467] notify_change+0x341/0x4e0 [93.847805] ? lock_acquire+0xf8/0x110 [93.849143] ? do_truncate+0x74/0xe0 [93.8504
[93.846467] notify_change+0x341/0x4e0 [93.847805] ? lock_acquire+0xf8/0x110 [93.849143] ? do_truncate+0x74/0xe0 [93.850452] ? do_truncate+0x84/0xe0 [93.851739] do_truncate+0x84/0xe0 [93.852974] do_sys_ftruncate+0x2b4/0x2f0 [93.854404] do_syscall_64+0x3f/0x90 [93.855789] entry_SYSCALL_64_after_hwframe+0x72/0xdc References: - https://git.kernel.org/stable/c/9e54fd14bd143c261e52fde74355e85e9526c58c - https://git.kernel.org/stable/c/5cee8bfb8cbd99c97aff85d2bf066b6a496e13ab - https://git.kernel.org/stable/c/fcced95b6ba2a507a83b8b3e0358a8ac16b13e35
CVE ID: CVE-2023-53324 State: PUBLISHED Published: 2025-09-16T16:11:59.672Z Last Updated: 2025-09-16T16:11:59.672Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Don't leak some plane state Apparently no one noticed that mdp5 plane states leak like a sieve ever since we introduced plane_state->commit refcount a few years ago in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.") Fix it by using the right helpers. Patchwork: https://patchwork.freedesktop.org/patch/551236/ References: - https://git.kernel.org/stable/c/7fc11a830b2eb07a0e3c6f917e5e636df6fc5d4c - https://gi
op.org/patch/551236/ References: - https://git.kernel.org/stable/c/7fc11a830b2eb07a0e3c6f917e5e636df6fc5d4c - https://git.kernel.org/stable/c/b8a61df6f40448cf46611f7af05b00970d08d620 - https://git.kernel.org/stable/c/815e42029f6e1e762898079f85546d6a0391ab95 - https://git.kernel.org/stable/c/c0b1eee648702e04f1005d451f9689575b7f52ed - https://git.kernel.org/stable/c/2965015006ef18ca96d2eab9ebe6bca884c63291 - https://git.kernel.org/stable/c/5b0dd3a102f64996598bd1e8d8388848a7c561bc - https://git.kernel.org/stable/c/12dfd02cbd1a678fbd66be0c2f79d5299c4921a9 - https://git.kernel.org/stable/c/fd0ad3b2365c1c58aa5a761c18efc4817193beb6
CVE ID: CVE-2023-53325 State: PUBLISHED Published: 2025-09-16T16:12:00.595Z Last Updated: 2025-09-17T11:02:54.521Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer() Change logging from drm_{err,info}() to dev_{err,info}() in functions mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be essential to avoid getting NULL pointer kernel panics if any kind of error happens during AUX transfers happening before the bridge is attached. This may potentially start happening in a later commit implementing aux-bus support, as AUX transfers will be triggered from th
y potentially start happening in a later commit implementing aux-bus support, as AUX transfers will be triggered from the panel driver (for EDID) before the mtk-dp bridge gets attached, and it's done in preparation for the same. References: - https://git.kernel.org/stable/c/4c743c1dd2ee2a72951660b6798d4d7f7674f87b - https://git.kernel.org/stable/c/7839f62294039959076dd06232e07aec7f7d5b2b - https://git.kernel.org/stable/c/fd70e2019bfbcb0ed90c5e23839bf510ce6acf8f
CVE ID: CVE-2023-53326 State: PUBLISHED Published: 2025-09-16T16:12:01.464Z Last Updated: 2025-09-16T16:12:01.464Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc: Don't try to copy PPR for task with NULL pt_regs powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which from my (arguably very short) checking is not commonly done for other archs. This is fine, except when PF_IO_WORKER's have been created and the task does something that causes a coredump to be generated. Then we get this crash: Kernel attempted to read user page (160) - exploit attempt? (uid: 1000) BUG: Kernel NULL pointer dereference on read
sh: Kernel attempted to read user page (160) - exploit attempt? (uid: 1000) BUG: Kernel NULL pointer dereference on read at 0x00000160 Faulting instruction address: 0xc0000000000c3a60 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=32 NUMA pSeries Modules linked in: bochs drm_vram_helper drm_kms_helper xts binfmt_misc ecb ctr syscopyarea sysfillrect cbc sysimgblt drm_ttm_helper aes_generic ttm sg libaes evdev joydev virtio_balloon vmx_crypto gf128mul drm dm_mod fuse loop configfs drm_panel_orientation_quirks ip_tables x_tables autofs4 hid_generic usbhid hid xhci_pci xhci_hcd usbcore usb_common sd_mod CPU: 1 PID: 1982 Comm: ppc-crash Not tainted 6.3.0-rc2+
d_generic usbhid hid xhci_pci xhci_hcd usbcore usb_common sd_mod CPU: 1 PID: 1982 Comm: ppc-crash Not tainted 6.3.0-rc2+ #88 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries NIP: c0000000000c3a60 LR: c000000000039944 CTR: c0000000000398e0 REGS: c0000000041833b0 TRAP: 0300 Not tainted (6.3.0-rc2+) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 88082828 XER: 200400f8 ... NIP memcpy_power7+0x200/0x7d0 LR ppr_get+0x64/0xb0 Call Trace: ppr_get+0x40/0xb0 (unreliable) __regset_get+0x180/0x1f0 regset_get_alloc+0x64/0x90 elf_core_dump+0xb98/0x1b60 do_coredump+0x1c34/0x24a0 get_signal+0x71c/0x1410 do_notify_resume+0x140/0x6f0
loc+0x64/0x90 elf_core_dump+0xb98/0x1b60 do_coredump+0x1c34/0x24a0 get_signal+0x71c/0x1410 do_notify_resume+0x140/0x6f0 interrupt_exit_user_prepare_main+0x29c/0x320 interrupt_exit_user_prepare+0x6c/0xa0 interrupt_return_srr_user+0x8/0x138 Because ppr_get() is trying to copy from a PF_IO_WORKER with a NULL pt_regs. Check for a valid pt_regs in both ppc_get/ppr_set, and return an error if not set. The actual error value doesn't seem to be important here, so just pick -EINVAL. [mpe: Trim oops in change log, add Fixes & Cc stable] References: - https://git.kernel.org/stable/c/80a4200d51e5a7e046f4a90f5faa5bafd5a60c58 - https://git.kernel.org/stable/c/7624973bc15b76d000e8e6f9b8080fcb76d36595 - htt
0a4200d51e5a7e046f4a90f5faa5bafd5a60c58 - https://git.kernel.org/stable/c/7624973bc15b76d000e8e6f9b8080fcb76d36595 - https://git.kernel.org/stable/c/064a1c7b0f8403260d77627e62424a72ca26cee2 - https://git.kernel.org/stable/c/01849382373b867ddcbe7536b9dfa89f3bcea60e - https://git.kernel.org/stable/c/fd7276189450110ed835eb0a334e62d2f1c4e3be
CVE ID: CVE-2023-53327 State: PUBLISHED Published: 2025-09-16T16:12:03.417Z Last Updated: 2025-09-16T16:12:03.417Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommufd/selftest: Catch overflow of uptr and length syzkaller hits a WARN_ON when trying to have a uptr close to UINTPTR_MAX: WARNING: CPU: 1 PID: 393 at drivers/iommu/iommufd/selftest.c:403 iommufd_test+0xb19/0x16f0 Modules linked in: CPU: 1 PID: 393 Comm: repro Not tainted 6.2.0-c9c3395d5e3d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommufd_test+0xb19/0x16f0 Code: 94 c4 31 ff 44 89