xamxte/cve-to-cwe huggingface dataset:
CVE-2023-53709: In the Linux kernel, the following vulnerability has been resolved:  ring-buffer: Handle race between rb_move_tail and rb_check_pages  It seems a data race between ring_buffer writing and integrity check. That is, RB_FLAG of head_page is been updating, while at same time RB_FLAG was cleared when doing integrity check rb_check_pages():    rb_check_pages()            rb_handle_head_page():   --------                    --------   rb_head_page_deactivate()                               rb_head_page_set_normal()   rb_head_page_activate()  We do intergrity test of the list to check if the list is corrupted and it is still worth doing it. So, let's refactor rb_check_pages() such that we no longer clear and set flag during the list sanity checking.  [1] and [2] are the test to reproduce and the crash report respectively.  1: ``` read_trace.sh   while true;   do     # the "trace" file is closed after read     head -1 /sys/kernel/tracing/trace > /dev/null   done ``` ``` repro.sh   sysctl -w kernel.panic_on_warn=1   # function tracer will writing enough data into ring_buffer   echo function > /sys/kernel/tracing/current_tracer   ./read_trace.sh &   ./read_trace.sh &   ./read_trace.sh &   ./read_trace.sh &   ./read_trace.sh &   ./read_trace.sh &   ./read_trace.sh &   ./read_trace.sh & ```  2: ------------[ cut here ]------------ WARNING: CPU: 9 PID: 62 at kernel/trace/ring_buffer.c:2653 rb_move_tail+0x450/0x470 Modules linked in: CPU: 9 PID: 62 Comm: ksoftirqd/9 Tainted: G        W          6.2.0-rc6+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:rb_move_tail+0x450/0x470 Code: ff ff 4c 89 c8 f0 4d 0f b1 02 48 89 c2 48 83 e2 fc 49 39 d0 75 24 83 e0 03 83 f8 02 0f 84 e1 fb ff ff 48 8b 57 10 f0 ff 42 08 <0f> 0b 83 f8 02 0f 84 ce fb ff ff e9 db RSP: 0018:ffffb5564089bd00 EFLAGS: 00000203 RAX: 0000000000000000 RBX: ffff9db385a2bf81 RCX: ffffb5564089bd18 RDX: ffff9db281110100 RSI: 0000000000000fe4 RDI: ffff9db380145400 RBP: ffff9db385a2bf80 R08: ffff9db385a2bfc0 R09: ffff9db385a2bfc2 R10: ffff9db385a6c000 R11: ffff9db385a2bf80 R12: 0000000000000000 R13: 00000000000003e8 R14: ffff9db281110100 R15: ffffffffbb006108 FS:  0000000000000000(0000) GS:ffff9db3bdcc0000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005602323024c8 CR3: 0000000022e0c000 CR4: 00000000000006e0 Call Trace:  <TASK>  ring_buffer_lock_reserve+0x136/0x360  ? __do_softirq+0x287/0x2df  ? __pfx_rcu_softirq_qs+0x10/0x10  trace_function+0x21/0x110  ? __pfx_rcu_softirq_qs+0x10/0x10  ? __do_softirq+0x287/0x2df  function_trace_call+0xf6/0x120  0xffffffffc038f097  ? rcu_softirq_qs+0x5/0x140  rcu_softirq_qs+0x5/0x140  __do_softirq+0x287/0x2df  run_ksoftirqd+0x2a/0x30  smpboot_thread_fn+0x188/0x220  ? __pfx_smpboot_thread_fn+0x10/0x10  kthread+0xe7/0x110  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2c/0x50  </TASK> ---[ end trace 0000000000000000 ]---  [ crash report and test reproducer credit goes to Zheng Yejian]
CVE-2023-53710: In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7921: fix error code of return in mt7921_acpi_read  Kernel NULL pointer dereference when ACPI SAR table isn't implemented well. Fix the error code of return to mark the ACPI SAR table as invalid.  [    5.077128] mt7921e 0000:06:00.0: sar cnt = 0 [    5.077381] BUG: kernel NULL pointer dereference, address: 0000000000000004 [    5.077630] #PF: supervisor read access in kernel mode [    5.077883] #PF: error_code(0x0000) - not-present page [    5.078138] PGD 0 P4D 0 [    5.078398] Oops: 0000 [#1] PREEMPT SMP NOPTI [    5.079202] RIP: 0010:mt7921_init_acpi_sar+0x106/0x220 [mt7921_common] ... [    5.080786] Call Trace: [    5.080786]  <TASK> [    5.080786]  mt7921_register_device+0x37d/0x490 [mt7921_common] [    5.080786]  mt7921_pci_probe.part.0+0x2ee/0x310 [mt7921e] [    5.080786]  mt7921_pci_probe+0x52/0x70 [mt7921e] [    5.080786]  local_pci_probe+0x47/0x90 [    5.080786]  pci_call_probe+0x55/0x190 [    5.080786]  pci_device_probe+0x84/0x120
CVE-2023-53713: In the Linux kernel, the following vulnerability has been resolved:  arm64: sme: Use STR P to clear FFR context field in streaming SVE mode  The FFR is a predicate register which can vary between 16 and 256 bits in size depending upon the configured vector length. When saving the SVE state in streaming SVE mode, the FFR register is inaccessible and so commit 9f5848665788 ("arm64/sve: Make access to FFR optional") simply clears the FFR field of the in-memory context structure. Unfortunately, it achieves this using an unconditional 8-byte store and so if the SME vector length is anything other than 64 bytes in size we will either fail to clear the entire field or, worse, we will corrupt memory immediately following the structure. This has led to intermittent kfence splats in CI [1] and can trigger kmalloc Redzone corruption messages when running the 'fp-stress' kselftest:   | =============================================================================  | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten  | -----------------------------------------------------------------------------  |  | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc  | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531  |  __kmalloc+0x8c/0xcc  |  do_sme_acc+0x9c/0x220  |  ...  Replace the 8-byte store with a store of a predicate register which has been zero-initialised with PFALSE, ensuring that the entire field is cleared in memory.  [1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com
CVE-2023-53714: In the Linux kernel, the following vulnerability has been resolved:  drm/stm: ltdc: fix late dereference check  In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a container_of() before the pointer check. This could cause a kernel panic.  Fix this smatch warning: drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable dereferenced before check 'crtc' (see line 1119)
CVE-2023-53716: In the Linux kernel, the following vulnerability has been resolved:  net: fix skb leak in __skb_tstamp_tx()  Commit 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.") added a call to skb_orphan_frags_rx() to fix leaks with zerocopy skbs. But it ended up adding a leak of its own. When skb_orphan_frags_rx() fails, the function just returns, leaking the skb it just cloned. Free it before returning.  This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.
CVE-2023-53717: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()  Fix a stack-out-of-bounds write that occurs in a WMI response callback function that is called after a timeout occurs in ath9k_wmi_cmd(). The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer that could no longer be valid when a timeout occurs. Set wmi->last_seq_id to 0 when a timeout occurred.  Found by a modified version of syzkaller.  BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rx Write of size 4 Call Trace:  memcpy  ath9k_wmi_ctrl_rx  ath9k_htc_rx_msg  ath9k_hif_usb_reg_in_cb  __usb_hcd_giveback_urb  usb_hcd_giveback_urb  dummy_timer  call_timer_fn  run_timer_softirq  __do_softirq  irq_exit_rcu  sysvec_apic_timer_interrupt
CVE-2023-53719: In the Linux kernel, the following vulnerability has been resolved:  serial: arc_uart: fix of_iomap leak in `arc_serial_probe`  Smatch reports:  drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn: 'port->membase' from of_iomap() not released on lines: 631.  In arc_serial_probe(), if uart_add_one_port() fails, port->membase is not released, which would cause a resource leak.  To fix this, I replace of_iomap with devm_platform_ioremap_resource.
CVE-2023-53720: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Release the label when replacing existing ct entry  Cited commit doesn't release the label mapping when replacing existing ct entry which leads to following memleak report:  unreferenced object 0xffff8881854cf280 (size 96):   comm "kworker/u48:74", pid 23093, jiffies 4296664564 (age 175.944s)   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:     [<000000002722d368>] __kmalloc+0x4b/0x1c0     [<00000000cc44e18f>] mapping_add+0x6e8/0xc90 [mlx5_core]     [<000000003ad942a7>] mlx5_get_label_mapping+0x66/0xe0 [mlx5_core]     [<00000000266308ac>] mlx5_tc_ct_entry_create_mod_hdr+0x1c4/0xf50 [mlx5_core]     [<000000009a768b4f>] mlx5_tc_ct_entry_add_rule+0x16f/0xaf0 [mlx5_core]     [<00000000a178f3e5>] mlx5_tc_ct_block_flow_offload_add+0x10cb/0x1f90 [mlx5_core]     [<000000007b46c496>] mlx5_tc_ct_block_flow_offload+0x14a/0x630 [mlx5_core]     [<00000000a9a18ac5>] nf_flow_offload_tuple+0x1a3/0x390 [nf_flow_table]     [<00000000d0881951>] flow_offload_work_handler+0x257/0xd30 [nf_flow_table]     [<000000009e4935a4>] process_one_work+0x7c2/0x13e0     [<00000000f5cd36a7>] worker_thread+0x59d/0xec0     [<00000000baed1daf>] kthread+0x28f/0x330     [<0000000063d282a4>] ret_from_fork+0x1f/0x30  Fix the issue by correctly releasing the label mapping.
CVE-2023-53721: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath12k: Fix a NULL pointer dereference in ath12k_mac_op_hw_scan()  In ath12k_mac_op_hw_scan(), the return value of kzalloc() is directly used in memcpy(), which may lead to a NULL pointer dereference on failure of kzalloc().  Fix this bug by adding a check of arg.extraie.ptr.  Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
CVE-2023-53722: In the Linux kernel, the following vulnerability has been resolved:  md: raid1: fix potential OOB in raid1_remove_disk()  If rddev->raid_disk is greater than mddev->raid_disks, there will be an out-of-bounds in raid1_remove_disk(). We have already found similar reports as follows:  1) commit d17f744e883b ("md-raid10: fix KASAN warning") 2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")  Fix this bug by checking whether the "number" variable is valid.
CVE-2023-53724: In the Linux kernel, the following vulnerability has been resolved:  mfd: pcf50633-adc: Fix potential memleak in pcf50633_adc_async_read()  `req` is allocated in pcf50633_adc_async_read(), but adc_enqueue_request() could fail to insert the `req` into queue. We need to check the return value and free it in the case of failure.
CVE-2023-53725: In the Linux kernel, the following vulnerability has been resolved:  clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probe  Smatch reports: drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe() warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.  timer_baseaddr may have the problem of not being released after use, I replaced it with the devm_of_iomap() function and added the clk_put() function to cleanup the "clk_ce" and "clk_cs".
CVE-2023-53726: In the Linux kernel, the following vulnerability has been resolved:  arm64: csum: Fix OoB access in IP checksum code for negative lengths  Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length calls") added an early return for zero-length input, syzkaller has popped up with an example of a _negative_ length which causes an undefined shift and an out-of-bounds read:   | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39  | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975  |  | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0  | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023  | Call trace:  |  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233  |  show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240  |  __dump_stack lib/dump_stack.c:88 [inline]  |  dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106  |  print_address_description mm/kasan/report.c:351 [inline]  |  print_report+0x174/0x514 mm/kasan/report.c:462  |  kasan_report+0xd4/0x130 mm/kasan/report.c:572  |  kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187  |  __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31  |  do_csum+0x44/0x254 arch/arm64/lib/csum.c:39  |  csum_partial+0x30/0x58 lib/checksum.c:128  |  gso_make_checksum include/linux/skbuff.h:4928 [inline]  |  __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332  |  udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47  |  ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119  |  skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141  |  __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401  |  skb_gso_segment include/linux/netdevice.h:4859 [inline]  |  validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659  |  validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709  |  sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327  |  __dev_xmit_skb net/core/dev.c:3805 [inline]  |  __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210  |  dev_queue_xmit include/linux/netdevice.h:3085 [inline]  |  packet_xmit+0x6c/0x318 net/packet/af_packet.c:276  |  packet_snd net/packet/af_packet.c:3081 [inline]  |  packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113  |  sock_sendmsg_nosec net/socket.c:724 [inline]  |  sock_sendmsg net/socket.c:747 [inline]  |  __sys_sendto+0x3b4/0x538 net/socket.c:2144  Extend the early return to reject negative lengths as well, aligning our implementation with the generic code in lib/checksum.c
CVE-2023-53727: In the Linux kernel, the following vulnerability has been resolved:  net/sched: fq_pie: avoid stalls in fq_pie_timer()  When setting a high number of flows (limit being 65536), fq_pie_timer() is currently using too much time as syzbot reported.  Add logic to yield the cpu every 2048 flows (less than 150 usec on debug kernels). It should also help by not blocking qdisc fast paths for too long. Worst case (65536 flows) would need 31 jiffies for a complete scan.  Relevant extract from syzbot report:  rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/. rcu: blocking rcu_node structures (internal RCU debug): Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline] RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236 Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00 <a9> 00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8b RSP: 0018:ffffc90000007bb8 EFLAGS: 00000206 RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0 RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS:  0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <NMI>  </NMI>  <IRQ>  pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415  fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387  call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700
CVE-2023-53728: In the Linux kernel, the following vulnerability has been resolved:  posix-timers: Ensure timer ID search-loop limit is valid  posix_timer_add() tries to allocate a posix timer ID by starting from the cached ID which was stored by the last successful allocation.  This is done in a loop searching the ID space for a free slot one by one. The loop has to terminate when the search wrapped around to the starting point.  But that's racy vs. establishing the starting point. That is read out lockless, which leads to the following problem:  CPU0                    CPU1 posix_timer_add()   start = sig->posix_timer_id;   lock(hash_lock);   ...       posix_timer_add()   if (++sig->posix_timer_id < 0)                       start = sig->posix_timer_id;      sig->posix_timer_id = 0;  So CPU1 can observe a negative start value, i.e. -1, and the loop break never happens because the condition can never be true:    if (sig->posix_timer_id == start)      break;  While this is unlikely to ever turn into an endless loop as the ID space is huge (INT_MAX), the racy read of the start value caught the attention of KCSAN and Dmitry unearthed that incorrectness.  Rewrite it so that all id operations are under the hash lock.
CVE-2023-53729: In the Linux kernel, the following vulnerability has been resolved:  soc: qcom: qmi_encdec: Restrict string length in decode  The QMI TLV value for strings in a lot of qmi element info structures account for null terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of bounds access when the NULL character is appended in decoding.
CVE-2023-53731: In the Linux kernel, the following vulnerability has been resolved:  netlink: fix potential deadlock in netlink_set_err()  syzbot reported a possible deadlock in netlink_set_err() [1]  A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs for netlink_lock_table()") in netlink_lock_table()  This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump() which were not covered by cited commit.  [1]  WARNING: possible irq lock inversion dependency detected 6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted  syz-executor.2/23011 just changed the state of lock: ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612 but this lock was taken by another, SOFTIRQ-safe lock in the past:  (&local->queue_stop_reason_lock){..-.}-{2:2}  and interrupts could create inverse lock ordering between them.  other info that might help us debug this:  Possible interrupt unsafe locking scenario:         CPU0                    CPU1        ----                    ----   lock(nl_table_lock);                                local_irq_disable();                                lock(&local->queue_stop_reason_lock);                                lock(nl_table_lock);   <Interrupt>     lock(&local->queue_stop_reason_lock);   *** DEADLOCK ***
CVE-2023-53732: In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Fix NULL dereference in ni_write_inode  Syzbot reports a NULL dereference in ni_write_inode. When creating a new inode, if allocation fails in mi_init function (called in mi_format_new function), mi->mrec is set to NULL. In the error path of this inode creation, mi->mrec is later dereferenced in ni_write_inode.  Add a NULL check to prevent NULL dereference.
CVE-2025-40018: In the Linux kernel, the following vulnerability has been resolved:  ipvs: Defer ip_vs_ftp unregister during netns cleanup  On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.  Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately.
CVE-2025-40022: In the Linux kernel, the following vulnerability has been resolved:  crypto: af_alg - Fix incorrect boolean values in af_alg_ctx  Commit 1b34cbbf4f01 ("crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg") changed some fields from bool to 1-bit bitfields of type u32.  However, some assignments to these fields, specifically 'more' and 'merge', assign values greater than 1.  These relied on C's implicit conversion to bool, such that zero becomes false and nonzero becomes true.  With a 1-bit bitfields of type u32 instead, mod 2 of the value is taken instead, resulting in 0 being assigned in some cases when 1 was intended.  Fix this by restoring the bool type.
CVE-2025-40024: In the Linux kernel, the following vulnerability has been resolved:  vhost: Take a reference on the task in struct vhost_task.  vhost_task_create() creates a task and keeps a reference to its task_struct. That task may exit early via a signal and its task_struct will be released. A pending vhost_task_wake() will then attempt to wake the task and access a task_struct which is no longer there.  Acquire a reference on the task_struct while creating the thread and release the reference while the struct vhost_task itself is removed. If the task exits early due to a signal, then the vhost_task_wake() will still access a valid task_struct. The wake is safe and will be skipped in this case.
CVE-2025-40025: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on node footer for non inode dnode  As syzbot reported below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/file.c:1243! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5354 Comm: syz.0.0 Not tainted 6.17.0-rc1-syzkaller-00211-g90d970cade8e #0 PREEMPT(full) RIP: 0010:f2fs_truncate_hole+0x69e/0x6c0 fs/f2fs/file.c:1243 Call Trace:  <TASK>  f2fs_punch_hole+0x2db/0x330 fs/f2fs/file.c:1306  f2fs_fallocate+0x546/0x990 fs/f2fs/file.c:2018  vfs_fallocate+0x666/0x7e0 fs/open.c:342  ksys_fallocate fs/open.c:366 [inline]  __do_sys_fallocate fs/open.c:371 [inline]  __se_sys_fallocate fs/open.c:369 [inline]  __x64_sys_fallocate+0xc0/0x110 fs/open.c:369  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1e65f8ebe9  w/ a fuzzed image, f2fs may encounter panic due to it detects inconsistent truncation range in direct node in f2fs_truncate_hole().  The root cause is: a non-inode dnode may has the same footer.ino and footer.nid, so the dnode will be parsed as an inode, then ADDRS_PER_PAGE() may return wrong blkaddr count which may be 923 typically, by chance, dn.ofs_in_node is equal to 923, then count can be calculated to 0 in below statement, later it will trigger panic w/ f2fs_bug_on(, count == 0 || ...).   count = min(end_offset - dn.ofs_in_node, pg_end - pg_start);  This patch introduces a new node_type NODE_TYPE_NON_INODE, then allowing passing the new_type to sanity_check_node_footer in f2fs_get_node_folio() to detect corruption that a non-inode dnode has the same footer.ino and footer.nid.  Scripts to reproduce: mkfs.f2fs -f /dev/vdb mount /dev/vdb /mnt/f2fs touch /mnt/f2fs/foo touch /mnt/f2fs/bar dd if=/dev/zero of=/mnt/f2fs/foo bs=1M count=8 umount /mnt/f2fs inject.f2fs --node --mb i_nid --nid 4 --idx 0 --val 5 /dev/vdb mount /dev/vdb /mnt/f2fs xfs_io /mnt/f2fs/foo -c "fpunch 6984k 4k"