Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
https://git.kernel.org/stable/c/5d9c1b081ad28c852a97e10dd75412546497694a - https://git.kernel.org/stable/c/1084716f76c8045eadf92a9d9a62641f3c8d8c90 - https://git.kernel.org/stable/c/3e6de5037148c5a93a436b1e8d2edad3dac11755 - https://git.kernel.org/stable/c/9ba4416b831eeb4d185e88e73488d1d21288e63a - https://git.kernel.org/stable/c/5801f064e35181c71857a80ff18af4dbec3c5f5c
CVE ID: CVE-2022-49340 State: PUBLISHED Published: 2025-02-26T02:10:57.322Z Last Updated: 2025-05-04T12:44:28.114Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ip_gre: test csum_start instead of transport header GRE with TUNNEL_CSUM will apply local checksum offload on CHECKSUM_PARTIAL packets. ipgre_xmit must validate csum_start after an optional skb_pull, else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; This had false positives when skb_checksum_start is undefined: when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement was straightforward
hen skb_checksum_start is undefined: when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement was straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL; But was eventually revised more thoroughly: - restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull. - test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath. Turns out skbs can arrive in this branch without the transport header set, e.g., through BPF redirection. Revise the check back to check csum_start directly, and only if CHECKSUM_PARTIAL. Do
et, e.g., through BPF redirection. Revise the check back to check csum_start directly, and only if CHECKSUM_PARTIAL. Do leave the check in the updated location. Check field regardless of whether TUNNEL_CSUM is configured. References: - https://git.kernel.org/stable/c/7596bd7920985f7fc8579a92e48bc53ce4475b21 - https://git.kernel.org/stable/c/3d08bc3a5d9b2106f5c8bcf1adb73147824aa006 - https://git.kernel.org/stable/c/fbeb8dfa8b87ef259eef0c89e39b53962a3cf604 - https://git.kernel.org/stable/c/e6b6f98fc7605c06c0a3baa70f62c534d7b4ce58 - https://git.kernel.org/stable/c/0c92d813c7c9ca2212ecd879232e7d87362fce98 - https://git.kernel.org/stable/c/0ffa268724656633af5f37a38c212326d98ebe8c - https://git.ke
ca2212ecd879232e7d87362fce98 - https://git.kernel.org/stable/c/0ffa268724656633af5f37a38c212326d98ebe8c - https://git.kernel.org/stable/c/8d21e9963bec1aad2280cdd034c8993033ef2948
CVE ID: CVE-2022-49341 State: PUBLISHED Published: 2025-02-26T02:10:58.118Z Last Updated: 2025-05-04T08:35:40.168Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Clear prog->jited_len along prog->jited syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1] There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64. bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space. My theory is that syzbot managed to get a prog where prog->jited_len h
if the JIT image can be copied out to user space. My theory is that syzbot managed to get a prog where prog->jited_len has been set to 43, while prog->bpf_func has ben cleared. It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering this particular warning. I thought find_vma_area(NULL) would not find a vm_struct. As we do not hold vmap_area_lock spinlock, it might be possible that the found vm_struct was garbage. [1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller
r: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 747
b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865 x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830 x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064 Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [inline] __check_object_size mm/usercopy.c:252 [inline] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [inline] che
inline] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [inline] check_copy_size include/linux/thread_info.h:235 [inline] copy_to_user include/linux/uaccess.h:159 [inline] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [inline] __se_sys_bpf kernel/bpf/syscall.c:5019 [inline] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xe
ernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000) References: - https://git.kernel.org/stable/c/aaf61a312af63e1cfe2264c4c5b8cd4ea3626025 - https://git.kernel.org/stable/c/e412b3d178ea4bf746f6b8ee086761613704c6be - https://git.kernel.org/stable/c/0cf7aaff290cdc4d7cee683d4a18138b0dacac48 - https://git.kernel.or
6b8ee086761613704c6be - https://git.kernel.org/stable/c/0cf7aaff290cdc4d7cee683d4a18138b0dacac48 - https://git.kernel.org/stable/c/3f4d5e727aeaa610688d46c9f101f78b7f712583 - https://git.kernel.org/stable/c/5c25a3040bc0486c41a7b63a1fb0de7cdb846ad7 - https://git.kernel.org/stable/c/41f7c4f85d402043687e863627a1a84fa867c62d - https://git.kernel.org/stable/c/10f3b29c65bb2fe0d47c2945cd0b4087be1c5218
CVE ID: CVE-2022-49342 State: PUBLISHED Published: 2025-02-26T02:10:58.604Z Last Updated: 2025-10-01T19:46:55.020Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b51996e35bbfcc7a27d94dfeed5cc2429b2c0df4 - https://git.kernel.org/stable/c/7fb1fe7d9a167205413f1de8db9f7d0f82c78286 - https://git.
bfcc7a27d94dfeed5cc2429b2c0df4 - https://git.kernel.org/stable/c/7fb1fe7d9a167205413f1de8db9f7d0f82c78286 - https://git.kernel.org/stable/c/b8d91399775c55162073bb2aca061ec42e3d4bc1
CVE ID: CVE-2022-49343 State: PUBLISHED Published: 2025-02-26T02:10:59.970Z Last Updated: 2025-05-04T08:35:42.522Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: avoid cycles in directory h-tree A maliciously corrupted filesystem can contain cycles in the h-tree stored inside a directory. That can easily lead to the kernel corrupting tree nodes that were already verified under its hands while doing a node split and consequently accessing unallocated memory. Fix the problem by verifying traversed block numbers are unique. References: - https://git.kernel.org/stable/c/24b8206fec1db21d7e82f21f0b2ff5e5672cf5b3 - https://git.k
mbers are unique. References: - https://git.kernel.org/stable/c/24b8206fec1db21d7e82f21f0b2ff5e5672cf5b3 - https://git.kernel.org/stable/c/b3ad9ff6f06c1dc6abf7437691c88ca3d6da3ac0 - https://git.kernel.org/stable/c/e157c8f87e8fac112d6c955e69a60cdb9bc80a60 - https://git.kernel.org/stable/c/ff4cafa51762da3824881a9000ca421d4b78b138 - https://git.kernel.org/stable/c/3a3ce941645407cd0b0b7f01ad9e2ea3770f46cc - https://git.kernel.org/stable/c/d5a16a6df2c16eaf4de04948553ef0089dee463f - https://git.kernel.org/stable/c/6084240bfc44bf265ab6ae7d96980469b05be0f1 - https://git.kernel.org/stable/c/3ba733f879c2a88910744647e41edeefbc0d92b2
CVE ID: CVE-2022-49344 State: PUBLISHED Published: 2025-02-26T02:11:00.498Z Last Updated: 2025-10-01T19:46:54.869Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/95f0ba806277733bf6024e23e27e1be773701cca - https://git.kernel.org/stable/c/556720013c
- https://git.kernel.org/stable/c/95f0ba806277733bf6024e23e27e1be773701cca - https://git.kernel.org/stable/c/556720013c36c193d9cbfb06e7b33e51f0c39fbf - https://git.kernel.org/stable/c/c61848500a3fd6867dfa4834b8c7f97133eceb9f - https://git.kernel.org/stable/c/c926ae58f24f7bd55aa2ea4add9f952032507913 - https://git.kernel.org/stable/c/71e8bfc7f838cabc60cba24e09ca84c4f8321ab2 - https://git.kernel.org/stable/c/8801eb3ccd2e4e3b1a01449383e3321ae6dbd9d6 - https://git.kernel.org/stable/c/662a80946ce13633ae90a55379f1346c10f0c432
CVE ID: CVE-2022-49345 State: PUBLISHED Published: 2025-02-26T02:11:00.976Z Last Updated: 2025-05-04T08:35:44.901Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fi
ntly, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, net/ipv4/xfrm4_policy.c is never compiled as modular. (CONFIG_XFRM is boolean) References: - https://git.kernel.org/stable/c/c58d82a1264813e69119c13e9804e2e60b664ad5 - https://git.kernel.org/stable/c/e53cd3814504b2cadaba4d5a8a07eeea9ddacd03 - https://git.kernel.org/stable/c/31f3c6a4dcd3260a386e62cef2d5b36e902600a1 - https://git.kernel.org/stable/c/ef6d2354de238b065d8799c80da4be9a6af18e39 - https://git.kernel.org/stable/c/be3884d5cd04ccd58294b83a02d70b7c5fca19d3
e/c/ef6d2354de238b065d8799c80da4be9a6af18e39 - https://git.kernel.org/stable/c/be3884d5cd04ccd58294b83a02d70b7c5fca19d3 - https://git.kernel.org/stable/c/85a055c03691e51499123194a14a0c249cf33227 - https://git.kernel.org/stable/c/e04d59cfe0c0129df7aba7ef7bb17b96be2a64f2 - https://git.kernel.org/stable/c/2b253fbc9f7b5db18d716436bdcf8ecef09fd63d - https://git.kernel.org/stable/c/4a388f08d8784af48f352193d2b72aaf167a57a1
CVE ID: CVE-2022-49346 State: PUBLISHED Published: 2025-02-26T02:11:01.485Z Last Updated: 2025-10-01T19:46:54.721Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. when breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the gphy_fw_np. Add missing of_node_put() to avoid refcount leak. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7c8df6fad43d9d5d77f281f794b
tional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7c8df6fad43d9d5d77f281f794b2a93cd02fd1a9 - https://git.kernel.org/stable/c/c2ae49a113a5344232f1ebb93bcf18bbd11e9c39 - https://git.kernel.org/stable/c/54d6802c4d83fa8de7696cfec06f475d5fd92d27 - https://git.kernel.org/stable/c/32cd78c5610f02a929f63cac985e73692d05f33e - https://git.kernel.org/stable/c/2e007ac6fa7c9c94ad84da075c5c504afad690a0 - https://git.kernel.org/stable/c/0737e018a05e2aa352828c52bdeed3b02cff2930
CVE ID: CVE-2022-49347 State: PUBLISHED Published: 2025-02-26T02:11:01.983Z Last Updated: 2025-05-04T08:35:47.612Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in ext4_writepages we got issue as follows: EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls ------------[ cut here ]------------ kernel BUG at fs/ext4/inode.c:2708! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX
d 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000
0000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90 It may happen as follows: 1. write inline_data inode vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> If inline data size too small will allocate block to write, then mapping will has dirty page ext
te_inline_data_begin -> If inline data size too small will allocate block to write, then mapping will has dirty page ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA 2. fallocate do_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> fail will goto restore data ext4_restore_inline_data ext4_create_inline_data ext4_write_inline_data ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA 3. writepages __ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages if (ext4_has_inline_data(inode)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_I
_wbc do_writepages ext4_writepages if (ext4_has_inline_data(inode)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) The root cause of this issue is we destory inline data until call ext4_writepages under delay allocation mode. But there maybe already convert from inline to extent. To solve this issue, we call filemap_flush first.. References: - https://git.kernel.org/stable/c/19918ec7717d87d5ab825884a46b26b21375d7ce - https://git.kernel.org/stable/c/b2b78f5bf2d453dda3903955efee059260787a42 - https://git.kernel.org/stable/c/de1732b5c1693ad489c5d254f124f67cb775f37d - https://git.kernel.org/stable/c/73fd5b19285197078ee8a2e651d75d5b094a4de9 - https://git.kernel.org/stable/c/1b06
75f37d - https://git.kernel.org/stable/c/73fd5b19285197078ee8a2e651d75d5b094a4de9 - https://git.kernel.org/stable/c/1b061af037646c9cdb0afd8a8d2f1e1c06285866 - https://git.kernel.org/stable/c/18a759f7f99f0b65a08ff5b7e745fc405a42bde4 - https://git.kernel.org/stable/c/1cde35417edc0370fb0179a4e38b78a15350a8d0 - https://git.kernel.org/stable/c/013f12bdedb96816aaa27ee04349f4433d361f52 - https://git.kernel.org/stable/c/ef09ed5d37b84d18562b30cf7253e57062d0db05
CVE ID: CVE-2022-49348 State: PUBLISHED Published: 2025-02-26T02:11:02.518Z Last Updated: 2025-06-19T12:56:18.264Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state The EXT4_FC_REPLAY bit in sbi->s_mount_state is used to indicate that we are in the middle of replay the fast commit journal. This was actually a mistake, since the sbi->s_mount_info is initialized from es->s_state. Arguably s_mount_state is misleadingly named, but the name is historical --- s_mount_state and s_state dates back to ext2. What should have been used is the ext4_{set,clear,test}_mount_fl
rical --- s_mount_state and s_state dates back to ext2. What should have been used is the ext4_{set,clear,test}_mount_flag() inline functions, which sets EXT4_MF_* bits in sbi->s_mount_flags. The problem with using EXT4_FC_REPLAY is that a maliciously corrupted superblock could result in EXT4_FC_REPLAY getting set in s_mount_state. This bypasses some sanity checks, and this can trigger a BUG() in ext4_es_cache_extent(). As a easy-to-backport-fix, filter out the EXT4_FC_REPLAY bit for now. We should eventually transition away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY. References: - https://git.kernel.org/stable/c/cc5b09cb6dacd4b32640537929ab4ee8fb2b9e04 - https://git.kernel.org/sta
LAY. References: - https://git.kernel.org/stable/c/cc5b09cb6dacd4b32640537929ab4ee8fb2b9e04 - https://git.kernel.org/stable/c/b99fd73418350dea360da8311e87a6a7b0e15a4c - https://git.kernel.org/stable/c/af2f1932743fb52ebcb008ad7ac500d9df0aa796 - https://git.kernel.org/stable/c/55b4dbb29054a05d839562f6d635ce05669b016d - https://git.kernel.org/stable/c/c878bea3c9d724ddfa05a813f30de3d25a0ba83f
CVE ID: CVE-2022-49349 State: PUBLISHED Published: 2025-02-26T02:11:02.993Z Last Updated: 2025-05-04T08:35:50.114Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_d
10beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: fffffff
e+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 000000000
0000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_r
f ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we r
. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ] Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1a3a15bf6f9963d755270cbdb282863b84839195 - https://git.kernel.org/stable/c/97f802a652a749422dede32071d29a53cf4bd034 - https://git.kernel.org/stable/c/10801095224de0d0ab06ae60698680c1f883a3ae - https://git.kernel.org/stable/c/eaecf7ebfd5dd09038a80b14be46b844f54cfc5c - https://git.kernel.org/stable/c/dd887f83ea54aea5b780a84527e23ab95f777fed - https://git.kernel.org/stable/c/364380c00912bed9b5d99eb485018360b0ecf64f - https
87f83ea54aea5b780a84527e23ab95f777fed - https://git.kernel.org/stable/c/364380c00912bed9b5d99eb485018360b0ecf64f - https://git.kernel.org/stable/c/0ff38b99fa075ddd246487a28cb9af049f4ceef1 - https://git.kernel.org/stable/c/4a2bea60cf7ff957b3eda0b17750d483876a02fa - https://git.kernel.org/stable/c/0be698ecbe4471fcad80e81ec6a05001421041b3