Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: bmips: BCM6358: disable RAC flush for TP1<br /> <br /> RAC flush causes kernel panics on BCM6358 with EHCI/OHCI when booting from TP1:<br /> [ 3.881739] usb 1-1: new high-speed USB device number 2 using ehci-platform<br /> [ 3.895011] Reserved instruction in kernel code[#1]:<br /> [ 3.900113] CPU: 0 PID: 1 Comm: init Not tainted 5.10.16 #0<br /> [ 3.905829] $ 0 : 00000000 10008700 00000000 77d94060<br /> [ 3.911238] $ 4 : 7fd1f088 00000000 81431cac 81431ca0<br /> [ 3.916641] $ 8 : 00000000 ffffefff 8075cd34 00000000<br /> [ 3.922043] $12 : 806f8d40 f3e812b7 00000000 000d9aaa<br /> [ 3.927446] $16 : 7fd1f068 7fd1f080 7ff559b8 81428470<br /> [ 3.932848] $20 : 00000000 00000000 55590000 77d70000<br /> [ 3.938251] $24 : 00000018 00000010<br /> [ 3.943655] $28 : 81430000 81431e60 81431f28 800157fc<br /> [ 3.949058] Hi : 00000000<br /> [ 3.952013] Lo : 00000000<br /> [ 3.955019] epc : 80015808 setup_sigcontext+0x54/0x24c<br /> [ 3.960464] ra : 800157fc setup_sigcontext+0x48/0x24c<br /> [ 3.965913] Status: 10008703 KERNEL EXL IE<br /> [ 3.970216] Cause : 00800028 (ExcCode 0a)<br /> [ 3.974340] PrId : 0002a010 (Broadcom BMIPS4350)<br /> [ 3.979170] Modules linked in: ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common<br /> [ 3.992907] Process init (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=77e22ec8)<br /> [ 4.000776] Stack : 81431ef4 7fd1f080 81431f28 81428470 7fd1f068 81431edc 7ff559b8 81428470<br /> [ 4.009467] 81431f28 7fd1f080 55590000 77d70000 77d5498c 80015c70 806f0000 8063ae74<br /> [ 4.018149] 08100002 81431f28 0000000a 08100002 81431f28 0000000a 77d6b418 00000003<br /> [ 4.026831] ffffffff 80016414 80080734 81431ecc 81431ecc 00000001 00000000 04000000<br /> [ 4.035512] 77d54874 00000000 00000000 00000000 00000000 00000012 00000002 00000000<br /> [ 4.044196] ...<br /> [ 4.046706] Call Trace:<br /> [ 4.049238] [] setup_sigcontext+0x54/0x24c<br /> [ 4.054356] [] setup_frame+0xdc/0x124<br /> [ 4.059015] [] do_notify_resume+0x1dc/0x288<br /> [ 4.064207] [] work_notifysig+0x10/0x18<br /> [ 4.069036]<br /> [ 4.070538] Code: 8fc300b4 00001025 26240008 ac830004 3c048063 0c0228aa 24846a00 26240010<br /> [ 4.080686]<br /> [ 4.082517] ---[ end trace 22a8edb41f5f983b ]---<br /> [ 4.087374] Kernel panic - not syncing: Fatal exception<br /> [ 4.092753] Rebooting in 1 seconds..<br /> <br /> Because the bootloader (CFE) is not initializing the Read-ahead cache properly<br /> on the second thread (TP1). Since the RAC was not initialized properly, we<br /> should avoid flushing it at the risk of corrupting the instruction stream as<br /> seen in the trace above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ping: Fix potentail NULL deref for /proc/net/icmp.<br /> <br /> After commit dbca1596bbb0 ("ping: convert to RCU lookups, get rid<br /> of rwlock"), we use RCU for ping sockets, but we should use spinlock<br /> for /proc/net/icmp to avoid a potential NULL deref mentioned in<br /> the previous patch.<br /> <br /> Let&amp;#39;s go back to using spinlock there.<br /> <br /> Note we can convert ping sockets to use hlist instead of hlist_nulls<br /> because we do not use SLAB_TYPESAFE_BY_RCU for ping sockets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix slab-out-of-bounds read in hdr_delete_de()<br /> <br /> Here is a BUG report from syzbot:<br /> <br /> BUG: KASAN: slab-out-of-bounds in hdr_delete_de+0xe0/0x150 fs/ntfs3/index.c:806<br /> Read of size 16842960 at addr ffff888079cc0600 by task syz-executor934/3631<br /> <br /> Call Trace:<br /> memmove+0x25/0x60 mm/kasan/shadow.c:54<br /> hdr_delete_de+0xe0/0x150 fs/ntfs3/index.c:806<br /> indx_delete_entry+0x74f/0x3670 fs/ntfs3/index.c:2193<br /> ni_remove_name+0x27a/0x980 fs/ntfs3/frecord.c:2910<br /> ntfs_unlink_inode+0x3d4/0x720 fs/ntfs3/inode.c:1712<br /> ntfs_rename+0x41a/0xcb0 fs/ntfs3/namei.c:276<br /> <br /> Before using the meta-data in struct INDEX_HDR, we need to<br /> check index header valid or not. Otherwise, the corruptedi<br /> (or malicious) fs image can cause out-of-bounds access which<br /> could make kernel panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mm: fix VA-range sanity check<br /> <br /> Both create_mapping_noalloc() and update_mapping_prot() sanity-check<br /> their &amp;#39;virt&amp;#39; parameter, but the check itself doesn&amp;#39;t make much sense.<br /> The condition used today appears to be a historical accident.<br /> <br /> The sanity-check condition:<br /> <br /> if ((virt &gt;= PAGE_END) &amp;&amp; (virt

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SMB3: Add missing locks to protect deferred close file list<br /> <br /> cifs_del_deferred_close function has a critical section which modifies<br /> the deferred close file list. We must acquire deferred_lock before<br /> calling cifs_del_deferred_close function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: enable use of both GFP_KERNEL and GFP_ATOMIC in convert_context()<br /> <br /> The following warning was triggered on a hardware environment:<br /> <br /> SELinux: Converting 162 SID table entries...<br /> BUG: sleeping function called from invalid context at<br /> __might_sleep+0x60/0x74 0x0<br /> in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 5943, name: tar<br /> CPU: 7 PID: 5943 Comm: tar Tainted: P O 5.10.0 #1<br /> Call trace:<br /> dump_backtrace+0x0/0x1c8<br /> show_stack+0x18/0x28<br /> dump_stack+0xe8/0x15c<br /> ___might_sleep+0x168/0x17c<br /> __might_sleep+0x60/0x74<br /> __kmalloc_track_caller+0xa0/0x7dc<br /> kstrdup+0x54/0xac<br /> convert_context+0x48/0x2e4<br /> sidtab_context_to_sid+0x1c4/0x36c<br /> security_context_to_sid_core+0x168/0x238<br /> security_context_to_sid_default+0x14/0x24<br /> inode_doinit_use_xattr+0x164/0x1e4<br /> inode_doinit_with_dentry+0x1c0/0x488<br /> selinux_d_instantiate+0x20/0x34<br /> security_d_instantiate+0x70/0xbc<br /> d_splice_alias+0x4c/0x3c0<br /> ext4_lookup+0x1d8/0x200 [ext4]<br /> __lookup_slow+0x12c/0x1e4<br /> walk_component+0x100/0x200<br /> path_lookupat+0x88/0x118<br /> filename_lookup+0x98/0x130<br /> user_path_at_empty+0x48/0x60<br /> vfs_statx+0x84/0x140<br /> vfs_fstatat+0x20/0x30<br /> __se_sys_newfstatat+0x30/0x74<br /> __arm64_sys_newfstatat+0x1c/0x2c<br /> el0_svc_common.constprop.0+0x100/0x184<br /> do_el0_svc+0x1c/0x2c<br /> el0_svc+0x20/0x34<br /> el0_sync_handler+0x80/0x17c<br /> el0_sync+0x13c/0x140<br /> SELinux: Context system_u:object_r:pssp_rsyslog_log_t:s0:c0 is<br /> not valid (left unmapped).<br /> <br /> It was found that within a critical section of spin_lock_irqsave in<br /> sidtab_context_to_sid(), convert_context() (hooked by<br /> sidtab_convert_params.func) might cause the process to sleep via<br /> allocating memory with GFP_KERNEL, which is problematic.<br /> <br /> As Ondrej pointed out [1], convert_context()/sidtab_convert_params.func<br /> has another caller sidtab_convert_tree(), which is okay with GFP_KERNEL.<br /> Therefore, fix this problem by adding a gfp_t argument for<br /> convert_context()/sidtab_convert_params.func and pass GFP_KERNEL/_ATOMIC<br /> properly in individual callers.<br /> <br /> [PM: wrap long BUG() output lines, tweak subject line]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: Delay the unmapping of the buffer<br /> <br /> On WCN3990, we are seeing a rare scenario where copy engine hardware is<br /> sending a copy complete interrupt to the host driver while still<br /> processing the buffer that the driver has sent, this is leading into an<br /> SMMU fault triggering kernel panic. This is happening on copy engine<br /> channel 3 (CE3) where the driver normally enqueues WMI commands to the<br /> firmware. Upon receiving a copy complete interrupt, host driver will<br /> immediately unmap and frees the buffer presuming that hardware has<br /> processed the buffer. In the issue case, upon receiving copy complete<br /> interrupt, host driver will unmap and free the buffer but since hardware<br /> is still accessing the buffer (which in this case got unmapped in<br /> parallel), SMMU hardware will trigger an SMMU fault resulting in a<br /> kernel panic.<br /> <br /> In order to avoid this, as a work around, add a delay before unmapping<br /> the copy engine source DMA buffer. This is conditionally done for<br /> WCN3990 and only for the CE3 channel where issue is seen.<br /> <br /> Below is the crash signature:<br /> <br /> wifi smmu error: kernel: [ 10.120965] arm-smmu 15000000.iommu: Unhandled<br /> context fault: fsr=0x402, iova=0x7fdfd8ac0,<br /> fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandled<br /> context fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003,<br /> cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal error<br /> received: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091:<br /> cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149<br /> remoteproc remoteproc0: crash detected in<br /> 4080000.remoteproc: type fatal error remoteproc remoteproc0:<br /> handling crash #1 in 4080000.remoteproc<br /> <br /> pc : __arm_lpae_unmap+0x500/0x514<br /> lr : __arm_lpae_unmap+0x4bc/0x514<br /> sp : ffffffc011ffb530<br /> x29: ffffffc011ffb590 x28: 0000000000000000<br /> x27: 0000000000000000 x26: 0000000000000004<br /> x25: 0000000000000003 x24: ffffffc011ffb890<br /> x23: ffffffa762ef9be0 x22: ffffffa77244ef00<br /> x21: 0000000000000009 x20: 00000007fff7c000<br /> x19: 0000000000000003 x18: 0000000000000000<br /> x17: 0000000000000004 x16: ffffffd7a357d9f0<br /> x15: 0000000000000000 x14: 00fd5d4fa7ffffff<br /> x13: 000000000000000e x12: 0000000000000000<br /> x11: 00000000ffffffff x10: 00000000fffffe00<br /> x9 : 000000000000017c x8 : 000000000000000c<br /> x7 : 0000000000000000 x6 : ffffffa762ef9000<br /> x5 : 0000000000000003 x4 : 0000000000000004<br /> x3 : 0000000000001000 x2 : 00000007fff7c000<br /> x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace:<br /> __arm_lpae_unmap+0x500/0x514<br /> __arm_lpae_unmap+0x4bc/0x514<br /> __arm_lpae_unmap+0x4bc/0x514<br /> arm_lpae_unmap_pages+0x78/0xa4<br /> arm_smmu_unmap_pages+0x78/0x104<br /> __iommu_unmap+0xc8/0x1e4<br /> iommu_unmap_fast+0x38/0x48<br /> __iommu_dma_unmap+0x84/0x104<br /> iommu_dma_free+0x34/0x50<br /> dma_free_attrs+0xa4/0xd0<br /> ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c<br /> [ath10k_core]<br /> ath10k_halt+0x11c/0x180 [ath10k_core]<br /> ath10k_stop+0x54/0x94 [ath10k_core]<br /> drv_stop+0x48/0x1c8 [mac80211]<br /> ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c<br /> [mac80211]<br /> __dev_open+0xb4/0x174<br /> __dev_change_flags+0xc4/0x1dc<br /> dev_change_flags+0x3c/0x7c<br /> devinet_ioctl+0x2b4/0x580<br /> inet_ioctl+0xb0/0x1b4<br /> sock_do_ioctl+0x4c/0x16c<br /> compat_ifreq_ioctl+0x1cc/0x35c<br /> compat_sock_ioctl+0x110/0x2ac<br /> __arm64_compat_sys_ioctl+0xf4/0x3e0<br /> el0_svc_common+0xb4/0x17c<br /> el0_svc_compat_handler+0x2c/0x58<br /> el0_svc_compat+0x8/0x2c<br /> <br /> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921s: fix slab-out-of-bounds access in sdio host<br /> <br /> SDIO may need addtional 511 bytes to align bus operation. If the tailroom<br /> of this skb is not big enough, we would access invalid memory region.<br /> For low level operation, increase skb size to keep valid memory access in<br /> SDIO host.<br /> <br /> Error message:<br /> [69.951] BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0xe9/0x1a0<br /> [69.951] Read of size 64 at addr ffff88811c9cf000 by task kworker/u16:7/451<br /> [69.951] CPU: 4 PID: 451 Comm: kworker/u16:7 Tainted: G W OE 6.1.0-rc5 #1<br /> [69.951] Workqueue: kvub300c vub300_cmndwork_thread [vub300]<br /> [69.951] Call Trace:<br /> [69.951] <br /> [69.952] dump_stack_lvl+0x49/0x63<br /> [69.952] print_report+0x171/0x4a8<br /> [69.952] kasan_report+0xb4/0x130<br /> [69.952] kasan_check_range+0x149/0x1e0<br /> [69.952] memcpy+0x24/0x70<br /> [69.952] sg_copy_buffer+0xe9/0x1a0<br /> [69.952] sg_copy_to_buffer+0x12/0x20<br /> [69.952] __command_write_data.isra.0+0x23c/0xbf0 [vub300]<br /> [69.952] vub300_cmndwork_thread+0x17f3/0x58b0 [vub300]<br /> [69.952] process_one_work+0x7ee/0x1320<br /> [69.952] worker_thread+0x53c/0x1240<br /> [69.952] kthread+0x2b8/0x370<br /> [69.952] ret_from_fork+0x1f/0x30<br /> [69.952] <br /> <br /> [69.952] Allocated by task 854:<br /> [69.952] kasan_save_stack+0x26/0x50<br /> [69.952] kasan_set_track+0x25/0x30<br /> [69.952] kasan_save_alloc_info+0x1b/0x30<br /> [69.952] __kasan_kmalloc+0x87/0xa0<br /> [69.952] __kmalloc_node_track_caller+0x63/0x150<br /> [69.952] kmalloc_reserve+0x31/0xd0<br /> [69.952] __alloc_skb+0xfc/0x2b0<br /> [69.952] __mt76_mcu_msg_alloc+0xbf/0x230 [mt76]<br /> [69.952] mt76_mcu_send_and_get_msg+0xab/0x110 [mt76]<br /> [69.952] __mt76_mcu_send_firmware.cold+0x94/0x15d [mt76]<br /> [69.952] mt76_connac_mcu_send_ram_firmware+0x415/0x54d [mt76_connac_lib]<br /> [69.952] mt76_connac2_load_ram.cold+0x118/0x4bc [mt76_connac_lib]<br /> [69.952] mt7921_run_firmware.cold+0x2e9/0x405 [mt7921_common]<br /> [69.952] mt7921s_mcu_init+0x45/0x80 [mt7921s]<br /> [69.953] mt7921_init_work+0xe1/0x2a0 [mt7921_common]<br /> [69.953] process_one_work+0x7ee/0x1320<br /> [69.953] worker_thread+0x53c/0x1240<br /> [69.953] kthread+0x2b8/0x370<br /> [69.953] ret_from_fork+0x1f/0x30<br /> [69.953] The buggy address belongs to the object at ffff88811c9ce800<br /> which belongs to the cache kmalloc-2k of size 2048<br /> [69.953] The buggy address is located 0 bytes to the right of<br /> 2048-byte region [ffff88811c9ce800, ffff88811c9cf000)<br /> <br /> [69.953] Memory state around the buggy address:<br /> [69.953] ffff88811c9cef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [69.953] ffff88811c9cef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [69.953] &gt;ffff88811c9cf000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [69.953] ^<br /> [69.953] ffff88811c9cf080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [69.953] ffff88811c9cf100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa_sim: fix possible memory leak in vdpasim_net_init() and vdpasim_blk_init()<br /> <br /> Inject fault while probing module, if device_register() fails in<br /> vdpasim_net_init() or vdpasim_blk_init(), but the refcount of kobject is<br /> not decreased to 0, the name allocated in dev_set_name() is leaked.<br /> Fix this by calling put_device(), so that name can be freed in<br /> callback function kobject_cleanup().<br /> <br /> (vdpa_sim_net)<br /> unreferenced object 0xffff88807eebc370 (size 16):<br /> comm "modprobe", pid 3848, jiffies 4362982860 (age 18.153s)<br /> hex dump (first 16 bytes):<br /> 76 64 70 61 73 69 6d 5f 6e 65 74 00 6b 6b 6b a5 vdpasim_net.kkk.<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x4e/0x150<br /> [] kstrdup+0x33/0x60<br /> [] kobject_set_name_vargs+0x41/0x110<br /> [] dev_set_name+0xab/0xe0<br /> [] device_add+0xe3/0x1a80<br /> [] 0xffffffffa0270013<br /> [] do_one_initcall+0x87/0x2e0<br /> [] do_init_module+0x1ab/0x640<br /> [] load_module+0x5d00/0x77f0<br /> [] __do_sys_finit_module+0x110/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> (vdpa_sim_blk)<br /> unreferenced object 0xffff8881070c1250 (size 16):<br /> comm "modprobe", pid 6844, jiffies 4364069319 (age 17.572s)<br /> hex dump (first 16 bytes):<br /> 76 64 70 61 73 69 6d 5f 62 6c 6b 00 6b 6b 6b a5 vdpasim_blk.kkk.<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x4e/0x150<br /> [] kstrdup+0x33/0x60<br /> [] kobject_set_name_vargs+0x41/0x110<br /> [] dev_set_name+0xab/0xe0<br /> [] device_add+0xe3/0x1a80<br /> [] 0xffffffffa0220013<br /> [] do_one_initcall+0x87/0x2e0<br /> [] do_init_module+0x1ab/0x640<br /> [] load_module+0x5d00/0x77f0<br /> [] __do_sys_finit_module+0x110/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: smsm: Fix refcount leak bugs in qcom_smsm_probe()<br /> <br /> There are two refcount leak bugs in qcom_smsm_probe():<br /> <br /> (1) The &amp;#39;local_node&amp;#39; is escaped out from for_each_child_of_node() as<br /> the break of iteration, we should call of_node_put() for it in error<br /> path or when it is not used anymore.<br /> (2) The &amp;#39;node&amp;#39; is escaped out from for_each_available_child_of_node()<br /> as the &amp;#39;goto&amp;#39;, we should call of_node_put() for it in goto target.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: Fix use-after-free during usb config switch<br /> <br /> In the process of switching USB config from rndis to other config,<br /> if the hardware does not support the -&gt;pullup callback, or the<br /> hardware encounters a low probability fault, both of them may cause<br /> the -&gt;pullup callback to fail, which will then cause a system panic<br /> (use after free).<br /> <br /> The gadget drivers sometimes need to be unloaded regardless of the<br /> hardware&amp;#39;s behavior.<br /> <br /> Analysis as follows:<br /> =======================================================================<br /> (1) write /config/usb_gadget/g1/UDC "none"<br /> <br /> gether_disconnect+0x2c/0x1f8<br /> rndis_disable+0x4c/0x74<br /> composite_disconnect+0x74/0xb0<br /> configfs_composite_disconnect+0x60/0x7c<br /> usb_gadget_disconnect+0x70/0x124<br /> usb_gadget_unregister_driver+0xc8/0x1d8<br /> gadget_dev_desc_UDC_store+0xec/0x1e4<br /> <br /> (2) rm /config/usb_gadget/g1/configs/b.1/f1<br /> <br /> rndis_deregister+0x28/0x54<br /> rndis_free+0x44/0x7c<br /> usb_put_function+0x14/0x1c<br /> config_usb_cfg_unlink+0xc4/0xe0<br /> configfs_unlink+0x124/0x1c8<br /> vfs_unlink+0x114/0x1dc<br /> <br /> (3) rmdir /config/usb_gadget/g1/functions/rndis.gs4<br /> <br /> panic+0x1fc/0x3d0<br /> do_page_fault+0xa8/0x46c<br /> do_mem_abort+0x3c/0xac<br /> el1_sync_handler+0x40/0x78<br /> 0xffffff801138f880<br /> rndis_close+0x28/0x34<br /> eth_stop+0x74/0x110<br /> dev_close_many+0x48/0x194<br /> rollback_registered_many+0x118/0x814<br /> unregister_netdev+0x20/0x30<br /> gether_cleanup+0x1c/0x38<br /> rndis_attr_release+0xc/0x14<br /> kref_put+0x74/0xb8<br /> configfs_rmdir+0x314/0x374<br /> <br /> If gadget-&gt;ops-&gt;pullup() return an error, function rndis_close() will be<br /> called, then it will causes a use-after-free problem.<br /> =======================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rw: defer fsnotify calls to task context<br /> <br /> We can&amp;#39;t call these off the kiocb completion as that might be off<br /> soft/hard irq context. Defer the calls to when we process the<br /> task_work for this request. That avoids valid complaints like:<br /> <br /> stack backtrace:<br /> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.0.0-rc6-syzkaller-00321-g105a36f3694e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_usage_bug kernel/locking/lockdep.c:3961 [inline]<br /> valid_state kernel/locking/lockdep.c:3973 [inline]<br /> mark_lock_irq kernel/locking/lockdep.c:4176 [inline]<br /> mark_lock.part.0.cold+0x18/0xd8 kernel/locking/lockdep.c:4632<br /> mark_lock kernel/locking/lockdep.c:4596 [inline]<br /> mark_usage kernel/locking/lockdep.c:4527 [inline]<br /> __lock_acquire+0x11d9/0x56d0 kernel/locking/lockdep.c:5007<br /> lock_acquire kernel/locking/lockdep.c:5666 [inline]<br /> lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631<br /> __fs_reclaim_acquire mm/page_alloc.c:4674 [inline]<br /> fs_reclaim_acquire+0x115/0x160 mm/page_alloc.c:4688<br /> might_alloc include/linux/sched/mm.h:271 [inline]<br /> slab_pre_alloc_hook mm/slab.h:700 [inline]<br /> slab_alloc mm/slab.c:3278 [inline]<br /> __kmem_cache_alloc_lru mm/slab.c:3471 [inline]<br /> kmem_cache_alloc+0x39/0x520 mm/slab.c:3491<br /> fanotify_alloc_fid_event fs/notify/fanotify/fanotify.c:580 [inline]<br /> fanotify_alloc_event fs/notify/fanotify/fanotify.c:813 [inline]<br /> fanotify_handle_event+0x1130/0x3f40 fs/notify/fanotify/fanotify.c:948<br /> send_to_group fs/notify/fsnotify.c:360 [inline]<br /> fsnotify+0xafb/0x1680 fs/notify/fsnotify.c:570<br /> __fsnotify_parent+0x62f/0xa60 fs/notify/fsnotify.c:230<br /> fsnotify_parent include/linux/fsnotify.h:77 [inline]<br /> fsnotify_file include/linux/fsnotify.h:99 [inline]<br /> fsnotify_access include/linux/fsnotify.h:309 [inline]<br /> __io_complete_rw_common+0x485/0x720 io_uring/rw.c:195<br /> io_complete_rw+0x1a/0x1f0 io_uring/rw.c:228<br /> iomap_dio_complete_work fs/iomap/direct-io.c:144 [inline]<br /> iomap_dio_bio_end_io+0x438/0x5e0 fs/iomap/direct-io.c:178<br /> bio_endio+0x5f9/0x780 block/bio.c:1564<br /> req_bio_endio block/blk-mq.c:695 [inline]<br /> blk_update_request+0x3fc/0x1300 block/blk-mq.c:825<br /> scsi_end_request+0x7a/0x9a0 drivers/scsi/scsi_lib.c:541<br /> scsi_io_completion+0x173/0x1f70 drivers/scsi/scsi_lib.c:971<br /> scsi_complete+0x122/0x3b0 drivers/scsi/scsi_lib.c:1438<br /> blk_complete_reqs+0xad/0xe0 block/blk-mq.c:1022<br /> __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571<br /> invoke_softirq kernel/softirq.c:445 [inline]<br /> __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650<br /> irq_exit_rcu+0x5/0x20 kernel/softirq.c:662<br /> common_interrupt+0xa9/0xc0 arch/x86/kernel/irq.c:240