Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost-vdpa: fix an iotlb memory leak<br /> <br /> Before commit 3d5698793897 ("vhost-vdpa: introduce asid based IOTLB")<br /> we called vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1) during<br /> release to free all the resources allocated when processing user IOTLB<br /> messages through vhost_vdpa_process_iotlb_update().<br /> That commit changed the handling of IOTLB a bit, and we accidentally<br /> removed some code called during the release.<br /> <br /> We partially fixed this with commit 037d4305569a ("vhost-vdpa: call<br /> vhost_vdpa_cleanup during the release") but a potential memory leak is<br /> still there as showed by kmemleak if the application does not send<br /> VHOST_IOTLB_INVALIDATE or crashes:<br /> <br /> unreferenced object 0xffff888007fbaa30 (size 16):<br /> comm "blkio-bench", pid 914, jiffies 4294993521 (age 885.500s)<br /> hex dump (first 16 bytes):<br /> 40 73 41 07 80 88 ff ff 00 00 00 00 00 00 00 00 @sA.............<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x142/0x1c0<br /> [] vhost_vdpa_process_iotlb_msg+0x68c/0x901 [vhost_vdpa]<br /> [] vhost_chr_write_iter+0xc0/0x4a0 [vhost]<br /> [] vhost_vdpa_chr_write_iter+0x18/0x20 [vhost_vdpa]<br /> [] vfs_write+0x216/0x4b0<br /> [] ksys_write+0x71/0xf0<br /> [] __x64_sys_write+0x19/0x20<br /> [] do_syscall_64+0x3f/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Let&amp;#39;s fix this calling vhost_vdpa_iotlb_unmap() on the whole range in<br /> vhost_vdpa_remove_as(). We move that call before vhost_dev_cleanup()<br /> since we need a valid v-&gt;vdev.mm in vhost_vdpa_pa_unmap().<br /> vhost_iotlb_reset() call can be removed, since vhost_vdpa_iotlb_unmap()<br /> on the whole range removes all the entries.<br /> <br /> The kmemleak log reported was observed with a vDPA device that has `use_va`<br /> set to true (e.g. VDUSE). This patch has been tested with both types of<br /> devices.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add null pointer check for inode operations<br /> <br /> This adds a sanity check for the i_op pointer of the inode which is<br /> returned after reading Root directory MFT record. We should check the<br /> i_op is valid before trying to create the root dentry, otherwise we may<br /> encounter a NPD while mounting a image with a funny Root directory MFT<br /> record.<br /> <br /> [ 114.484325] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [ 114.484811] #PF: supervisor read access in kernel mode<br /> [ 114.485084] #PF: error_code(0x0000) - not-present page<br /> [ 114.485606] PGD 0 P4D 0<br /> [ 114.485975] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> [ 114.486570] CPU: 0 PID: 237 Comm: mount Tainted: G B 6.0.0-rc4 #28<br /> [ 114.486977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 114.488169] RIP: 0010:d_flags_for_inode+0xe0/0x110<br /> [ 114.488816] Code: 24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 20 49 8d 7e 08 e8 60 241<br /> [ 114.490326] RSP: 0018:ffff8880065e7aa8 EFLAGS: 00000296<br /> [ 114.490695] RAX: 0000000000000001 RBX: ffff888008ccd750 RCX: ffffffff84af2aea<br /> [ 114.490986] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff87abd020<br /> [ 114.491364] RBP: ffff8880065e7ac8 R08: 0000000000000001 R09: fffffbfff0f57a05<br /> [ 114.491675] R10: ffffffff87abd027 R11: fffffbfff0f57a04 R12: 0000000000000000<br /> [ 114.491954] R13: 0000000000000008 R14: 0000000000000000 R15: ffff888008ccd750<br /> [ 114.492397] FS: 00007fdc8a627e40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000<br /> [ 114.492797] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 114.493150] CR2: 0000000000000008 CR3: 00000000013ba000 CR4: 00000000000006f0<br /> [ 114.493671] Call Trace:<br /> [ 114.493890] <br /> [ 114.494075] __d_instantiate+0x24/0x1c0<br /> [ 114.494505] d_instantiate.part.0+0x35/0x50<br /> [ 114.494754] d_make_root+0x53/0x80<br /> [ 114.494998] ntfs_fill_super+0x1232/0x1b50<br /> [ 114.495260] ? put_ntfs+0x1d0/0x1d0<br /> [ 114.495499] ? vsprintf+0x20/0x20<br /> [ 114.495723] ? set_blocksize+0x95/0x150<br /> [ 114.495964] get_tree_bdev+0x232/0x370<br /> [ 114.496272] ? put_ntfs+0x1d0/0x1d0<br /> [ 114.496502] ntfs_fs_get_tree+0x15/0x20<br /> [ 114.496859] vfs_get_tree+0x4c/0x130<br /> [ 114.497099] path_mount+0x654/0xfe0<br /> [ 114.497507] ? putname+0x80/0xa0<br /> [ 114.497933] ? finish_automount+0x2e0/0x2e0<br /> [ 114.498362] ? putname+0x80/0xa0<br /> [ 114.498571] ? kmem_cache_free+0x1c4/0x440<br /> [ 114.498819] ? putname+0x80/0xa0<br /> [ 114.499069] do_mount+0xd6/0xf0<br /> [ 114.499343] ? path_mount+0xfe0/0xfe0<br /> [ 114.499683] ? __kasan_check_write+0x14/0x20<br /> [ 114.500133] __x64_sys_mount+0xca/0x110<br /> [ 114.500592] do_syscall_64+0x3b/0x90<br /> [ 114.500930] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 114.501294] RIP: 0033:0x7fdc898e948a<br /> [ 114.501542] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 114.502716] RSP: 002b:00007ffd793e58f8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5<br /> [ 114.503175] RAX: ffffffffffffffda RBX: 0000564b2228f060 RCX: 00007fdc898e948a<br /> [ 114.503588] RDX: 0000564b2228f260 RSI: 0000564b2228f2e0 RDI: 0000564b22297ce0<br /> [ 114.504925] RBP: 0000000000000000 R08: 0000564b2228f280 R09: 0000000000000020<br /> [ 114.505484] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564b22297ce0<br /> [ 114.505823] R13: 0000564b2228f260 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 114.506562] <br /> [ 114.506887] Modules linked in:<br /> [ 114.507648] CR2: 0000000000000008<br /> [ 114.508884] ---[ end trace 0000000000000000 ]---<br /> [ 114.509675] RIP: 0010:d_flags_for_inode+0xe0/0x110<br /> [ 114.510140] Code: 24 f7 ff 49 83 3e 00 74 41 41 83 cd 02 66 44 89 6b 02 eb 92 48 8d 7b 20 e8 6d 24 f7 ff 4c 8b 73 20 49 8d 7e 08 e8 60 241<br /> [ 114.511762] RSP: 0018:ffff8880065e7aa8 EFLAGS: 00000296<br /> [ 114.512401] RAX: 0000000000000001 RBX: ffff888008ccd750 RCX: ffffffff84af2aea<br /> [ 114.51<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs()<br /> <br /> Syzkaller reports a long-known leak of urbs in<br /> ath9k_hif_usb_dealloc_tx_urbs().<br /> <br /> The cause of the leak is that usb_get_urb() is called but usb_free_urb()<br /> (or usb_put_urb()) is not called inside usb_kill_urb() as urb-&gt;dev or<br /> urb-&gt;ep fields have not been initialized and usb_kill_urb() returns<br /> immediately.<br /> <br /> The patch removes trying to kill urbs located in hif_dev-&gt;tx.tx_buf<br /> because hif_dev-&gt;tx.tx_buf is not supposed to contain urbs which are in<br /> pending state (the pending urbs are stored in hif_dev-&gt;tx.tx_pending).<br /> The tx.tx_lock is acquired so there should not be any changes in the list.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Disable useless interrupt to avoid kernel panic<br /> <br /> There is a hardware bug that the interrupt STMBUF_HALF may be triggered<br /> after or when disable interrupt.<br /> It may led to unexpected kernel panic.<br /> And interrupt STMBUF_HALF and STMBUF_RTND have no other effect.<br /> So disable them and the unused interrupts.<br /> <br /> meanwhile clear the interrupt status when disable interrupt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ocxl: fix possible refcount leak in afu_ioctl()<br /> <br /> eventfd_ctx_put need to be called to put the refcount that gotten by<br /> eventfd_ctx_fdget when ocxl_irq_set_handler fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: core: fix resource leak in regulator_register()<br /> <br /> I got some resource leak reports while doing fault injection test:<br /> <br /> OF: ERROR: memory leak, expected refcount 1 instead of 100,<br /> of_node_get()/of_node_put() unbalanced - destroy cset entry:<br /> attach overlay node /i2c/pmic@64/regulators/buck1<br /> <br /> unreferenced object 0xffff88810deea000 (size 512):<br /> comm "490-i2c-rt5190a", pid 253, jiffies 4294859840 (age 5061.046s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff ................<br /> backtrace:<br /> [] kmalloc_trace+0x21/0x110<br /> [] device_private_init+0x32/0xd0<br /> [] device_add+0xb2d/0x1030<br /> [] regulator_register+0xaf2/0x12a0<br /> [] devm_regulator_register+0x57/0xb0<br /> [] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]<br /> <br /> unreferenced object 0xffff88810b617b80 (size 32):<br /> comm "490-i2c-rt5190a", pid 253, jiffies 4294859904 (age 5060.983s)<br /> hex dump (first 32 bytes):<br /> 72 65 67 75 6c 61 74 6f 72 2e 32 38 36 38 2d 53 regulator.2868-S<br /> 55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00 UPPLY...)...+...<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x44/0x1b0<br /> [] kstrdup+0x3a/0x70<br /> [] create_regulator+0xc0/0x4e0<br /> [] regulator_resolve_supply+0x2d4/0x440<br /> [] regulator_register+0x10b3/0x12a0<br /> [] devm_regulator_register+0x57/0xb0<br /> [] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]<br /> <br /> After calling regulator_resolve_supply(), the &amp;#39;rdev-&gt;supply&amp;#39; is set<br /> by set_supply(), after this set, in the error path, the resources<br /> need be released, so call regulator_put() to avoid the leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: Fix use-after-free in vidtv_bridge_dvb_init()<br /> <br /> KASAN reports a use-after-free:<br /> BUG: KASAN: use-after-free in dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]<br /> Call Trace:<br /> ...<br /> dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]<br /> vidtv_bridge_probe+0x7bf/0xa40 [dvb_vidtv_bridge]<br /> platform_probe+0xb6/0x170<br /> ...<br /> Allocated by task 1238:<br /> ...<br /> dvb_register_device+0x1a7/0xa70 [dvb_core]<br /> dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]<br /> vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]<br /> ...<br /> Freed by task 1238:<br /> dvb_register_device+0x6d2/0xa70 [dvb_core]<br /> dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]<br /> vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]<br /> ...<br /> <br /> It is because the error handling in vidtv_bridge_dvb_init() is wrong.<br /> <br /> First, vidtv_bridge_dmx(dev)_init() will clean themselves when fail, but<br /> goto fail_dmx(_dev): calls release functions again, which causes<br /> use-after-free.<br /> <br /> Also, in fail_fe, fail_tuner_probe and fail_demod_probe, j = i will cause<br /> out-of-bound when i finished its loop (i == NUM_FE). And the loop<br /> releasing is wrong, although now NUM_FE is 1 so it won&amp;#39;t cause problem.<br /> <br /> Fix this by correctly releasing everything.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix possible use-after-free in async command interface<br /> <br /> mlx5_cmd_cleanup_async_ctx should return only after all its callback<br /> handlers were completed. Before this patch, the below race between<br /> mlx5_cmd_cleanup_async_ctx and mlx5_cmd_exec_cb_handler was possible and<br /> lead to a use-after-free:<br /> <br /> 1. mlx5_cmd_cleanup_async_ctx is called while num_inflight is 2 (i.e.<br /> elevated by 1, a single inflight callback).<br /> 2. mlx5_cmd_cleanup_async_ctx decreases num_inflight to 1.<br /> 3. mlx5_cmd_exec_cb_handler is called, decreases num_inflight to 0 and<br /> is about to call wake_up().<br /> 4. mlx5_cmd_cleanup_async_ctx calls wait_event, which returns<br /> immediately as the condition (num_inflight == 0) holds.<br /> 5. mlx5_cmd_cleanup_async_ctx returns.<br /> 6. The caller of mlx5_cmd_cleanup_async_ctx frees the mlx5_async_ctx<br /> object.<br /> 7. mlx5_cmd_exec_cb_handler goes on and calls wake_up() on the freed<br /> object.<br /> <br /> Fix it by syncing using a completion object. Mark it completed when<br /> num_inflight reaches 0.<br /> <br /> Trace:<br /> <br /> BUG: KASAN: use-after-free in do_raw_spin_lock+0x23d/0x270<br /> Read of size 4 at addr ffff888139cd12f4 by task swapper/5/0<br /> <br /> CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.0.0-rc3_for_upstream_debug_2022_08_30_13_10 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x57/0x7d<br /> print_report.cold+0x2d5/0x684<br /> ? do_raw_spin_lock+0x23d/0x270<br /> kasan_report+0xb1/0x1a0<br /> ? do_raw_spin_lock+0x23d/0x270<br /> do_raw_spin_lock+0x23d/0x270<br /> ? rwlock_bug.part.0+0x90/0x90<br /> ? __delete_object+0xb8/0x100<br /> ? lock_downgrade+0x6e0/0x6e0<br /> _raw_spin_lock_irqsave+0x43/0x60<br /> ? __wake_up_common_lock+0xb9/0x140<br /> __wake_up_common_lock+0xb9/0x140<br /> ? __wake_up_common+0x650/0x650<br /> ? destroy_tis_callback+0x53/0x70 [mlx5_core]<br /> ? kasan_set_track+0x21/0x30<br /> ? destroy_tis_callback+0x53/0x70 [mlx5_core]<br /> ? kfree+0x1ba/0x520<br /> ? do_raw_spin_unlock+0x54/0x220<br /> mlx5_cmd_exec_cb_handler+0x136/0x1a0 [mlx5_core]<br /> ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]<br /> ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]<br /> mlx5_cmd_comp_handler+0x65a/0x12b0 [mlx5_core]<br /> ? dump_command+0xcc0/0xcc0 [mlx5_core]<br /> ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> ? cmd_comp_notifier+0x7e/0xb0 [mlx5_core]<br /> cmd_comp_notifier+0x7e/0xb0 [mlx5_core]<br /> atomic_notifier_call_chain+0xd7/0x1d0<br /> mlx5_eq_async_int+0x3ce/0xa20 [mlx5_core]<br /> atomic_notifier_call_chain+0xd7/0x1d0<br /> ? irq_release+0x140/0x140 [mlx5_core]<br /> irq_int_handler+0x19/0x30 [mlx5_core]<br /> __handle_irq_event_percpu+0x1f2/0x620<br /> handle_irq_event+0xb2/0x1d0<br /> handle_edge_irq+0x21e/0xb00<br /> __common_interrupt+0x79/0x1a0<br /> common_interrupt+0x78/0xa0<br /> <br /> <br /> asm_common_interrupt+0x22/0x40<br /> RIP: 0010:default_idle+0x42/0x60<br /> Code: c1 83 e0 07 48 c1 e9 03 83 c0 03 0f b6 14 11 38 d0 7c 04 84 d2 75 14 8b 05 eb 47 22 02 85 c0 7e 07 0f 00 2d e0 9f 48 00 fb f4 48 c7 c7 80 08 7f 85 e8 d1 d3 3e fe eb de 66 66 2e 0f 1f 84 00<br /> RSP: 0018:ffff888100dbfdf0 EFLAGS: 00000242<br /> RAX: 0000000000000001 RBX: ffffffff84ecbd48 RCX: 1ffffffff0afe110<br /> RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff835cc9bc<br /> RBP: 0000000000000005 R08: 0000000000000001 R09: ffff88881dec4ac3<br /> R10: ffffed1103bd8958 R11: 0000017d0ca571c9 R12: 0000000000000005<br /> R13: ffffffff84f024e0 R14: 0000000000000000 R15: dffffc0000000000<br /> ? default_idle_call+0xcc/0x450<br /> default_idle_call+0xec/0x450<br /> do_idle+0x394/0x450<br /> ? arch_cpu_idle_exit+0x40/0x40<br /> ? do_idle+0x17/0x450<br /> cpu_startup_entry+0x19/0x20<br /> start_secondary+0x221/0x2b0<br /> ? set_cpu_sibling_map+0x2070/0x2070<br /> secondary_startup_64_no_verify+0xcd/0xdb<br /> <br /> <br /> Allocated by task 49502:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> kvmalloc_node+0x48/0xe0<br /> mlx5e_bulk_async_init+0x35/0x110 [mlx5_core]<br /> mlx5e_tls_priv_tx_list_cleanup+0x84/0x3e0 [mlx5_core]<br /> mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core]<br /> mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core]<br /> mlx5e_detach_netdev+0x1c<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: efct: Fix possible memleak in efct_device_init()<br /> <br /> In efct_device_init(), when efct_scsi_reg_fc_transport() fails,<br /> efct_scsi_tgt_driver_exit() is not called to release memory for<br /> efct_scsi_tgt_driver_init() and causes memleak:<br /> <br /> unreferenced object 0xffff8881020ce000 (size 2048):<br /> comm "modprobe", pid 465, jiffies 4294928222 (age 55.872s)<br /> backtrace:<br /> [] kmalloc_trace+0x27/0x110<br /> [] target_register_template+0x4fd/0x7b0 [target_core_mod]<br /> [] efct_scsi_tgt_driver_init+0x18/0x50 [efct]<br /> [] 0xffffffffc0d90011<br /> [] do_one_initcall+0xd0/0x4e0<br /> [] do_init_module+0x1cc/0x6a0<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/lcs: Fix return type of lcs_start_xmit()<br /> <br /> With clang&amp;#39;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),<br /> indirect call targets are validated against the expected function<br /> pointer prototype to make sure the call target is valid to help mitigate<br /> ROP attacks. If they are not identical, there is a failure at run time,<br /> which manifests as either a kernel panic or thread getting killed. A<br /> proposed warning in clang aims to catch these at compile time, which<br /> reveals:<br /> <br /> drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing &amp;#39;netdev_tx_t (*)(struct sk_buff *, struct net_device *)&amp;#39; (aka &amp;#39;enum netdev_tx (*)(struct sk_buff *, struct net_device *)&amp;#39;) with an expression of type &amp;#39;int (struct sk_buff *, struct net_device *)&amp;#39; [-Werror,-Wincompatible-function-pointer-types-strict]<br /> .ndo_start_xmit = lcs_start_xmit,<br /> ^~~~~~~~~~~~~~<br /> drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing &amp;#39;netdev_tx_t (*)(struct sk_buff *, struct net_device *)&amp;#39; (aka &amp;#39;enum netdev_tx (*)(struct sk_buff *, struct net_device *)&amp;#39;) with an expression of type &amp;#39;int (struct sk_buff *, struct net_device *)&amp;#39; [-Werror,-Wincompatible-function-pointer-types-strict]<br /> .ndo_start_xmit = lcs_start_xmit,<br /> ^~~~~~~~~~~~~~<br /> <br /> -&gt;ndo_start_xmit() in &amp;#39;struct net_device_ops&amp;#39; expects a return type of<br /> &amp;#39;netdev_tx_t&amp;#39;, not &amp;#39;int&amp;#39;. Adjust the return type of lcs_start_xmit() to<br /> match the prototype&amp;#39;s to resolve the warning and potential CFI failure,<br /> should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Fix resource leak in ksmbd_session_rpc_open()<br /> <br /> When ksmbd_rpc_open() fails then it must call ksmbd_rpc_id_free() to<br /> undo the result of ksmbd_ipc_id_alloc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: silence the warning when evicting inode with dioread_nolock<br /> <br /> When evicting an inode with default dioread_nolock, it could be raced by<br /> the unwritten extents converting kworker after writeback some new<br /> allocated dirty blocks. It convert unwritten extents to written, the<br /> extents could be merged to upper level and free extent blocks, so it<br /> could mark the inode dirty again even this inode has been marked<br /> I_FREEING. But the inode-&gt;i_io_list check and warning in<br /> ext4_evict_inode() missing this corner case. Fortunately,<br /> ext4_evict_inode() will wait all extents converting finished before this<br /> check, so it will not lead to inode use-after-free problem, every thing<br /> is OK besides this warning. The WARN_ON_ONCE was originally designed<br /> for finding inode use-after-free issues in advance, but if we add<br /> current dioread_nolock case in, it will become not quite useful, so fix<br /> this warning by just remove this check.<br /> <br /> ======<br /> WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227<br /> ext4_evict_inode+0x875/0xc60<br /> ...<br /> RIP: 0010:ext4_evict_inode+0x875/0xc60<br /> ...<br /> Call Trace:<br /> <br /> evict+0x11c/0x2b0<br /> iput+0x236/0x3a0<br /> do_unlinkat+0x1b4/0x490<br /> __x64_sys_unlinkat+0x4c/0xb0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7fa933c1115b<br /> ======<br /> <br /> rm kworker<br /> ext4_end_io_end()<br /> vfs_unlink()<br /> ext4_unlink()<br /> ext4_convert_unwritten_io_end_vec()<br /> ext4_convert_unwritten_extents()<br /> ext4_map_blocks()<br /> ext4_ext_map_blocks()<br /> ext4_ext_try_to_merge_up()<br /> __mark_inode_dirty()<br /> check !I_FREEING<br /> locked_inode_to_wb_and_lock_list()<br /> iput()<br /> iput_final()<br /> evict()<br /> ext4_evict_inode()<br /> truncate_inode_pages_final() //wait release io_end<br /> inode_io_list_move_locked()<br /> ext4_release_io_end()<br /> trigger WARN_ON_ONCE()