Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: hibernate: Avoid deadlock in hibernate_compressor_param_set()<br /> <br /> syzbot reported a deadlock in lock_system_sleep() (see below).<br /> <br /> The write operation to "/sys/module/hibernate/parameters/compressor"<br /> conflicts with the registration of ieee80211 device, resulting in a deadlock<br /> when attempting to acquire system_transition_mutex under param_lock.<br /> <br /> To avoid this deadlock, change hibernate_compressor_param_set() to use<br /> mutex_trylock() for attempting to acquire system_transition_mutex and<br /> return -EBUSY when it fails.<br /> <br /> Task flags need not be saved or adjusted before calling<br /> mutex_trylock(&amp;system_transition_mutex) because the caller is not going<br /> to end up waiting for this mutex and if it runs concurrently with system<br /> suspend in progress, it will be frozen properly when it returns to user<br /> space.<br /> <br /> syzbot report:<br /> <br /> syz-executor895/5833 is trying to acquire lock:<br /> ffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, at: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56<br /> <br /> but task is already holding lock:<br /> ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: kernel_param_lock kernel/params.c:607 [inline]<br /> ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: param_attr_store+0xe6/0x300 kernel/params.c:586<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #3 (param_lock){+.+.}-{4:4}:<br /> __mutex_lock_common kernel/locking/mutex.c:585 [inline]<br /> __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730<br /> ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [inline]<br /> rate_control_alloc net/mac80211/rate.c:266 [inline]<br /> ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015<br /> ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531<br /> mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558<br /> init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910<br /> do_one_initcall+0x128/0x700 init/main.c:1257<br /> do_initcall_level init/main.c:1319 [inline]<br /> do_initcalls init/main.c:1335 [inline]<br /> do_basic_setup init/main.c:1354 [inline]<br /> kernel_init_freeable+0x5c7/0x900 init/main.c:1568<br /> kernel_init+0x1c/0x2b0 init/main.c:1457<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> -&gt; #2 (rtnl_mutex){+.+.}-{4:4}:<br /> __mutex_lock_common kernel/locking/mutex.c:585 [inline]<br /> __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730<br /> wg_pm_notification drivers/net/wireguard/device.c:80 [inline]<br /> wg_pm_notification+0x49/0x180 drivers/net/wireguard/device.c:64<br /> notifier_call_chain+0xb7/0x410 kernel/notifier.c:85<br /> notifier_call_chain_robust kernel/notifier.c:120 [inline]<br /> blocking_notifier_call_chain_robust kernel/notifier.c:345 [inline]<br /> blocking_notifier_call_chain_robust+0xc9/0x170 kernel/notifier.c:333<br /> pm_notifier_call_chain_robust+0x27/0x60 kernel/power/main.c:102<br /> snapshot_open+0x189/0x2b0 kernel/power/user.c:77<br /> misc_open+0x35a/0x420 drivers/char/misc.c:179<br /> chrdev_open+0x237/0x6a0 fs/char_dev.c:414<br /> do_dentry_open+0x735/0x1c40 fs/open.c:956<br /> vfs_open+0x82/0x3f0 fs/open.c:1086<br /> do_open fs/namei.c:3830 [inline]<br /> path_openat+0x1e88/0x2d80 fs/namei.c:3989<br /> do_filp_open+0x20c/0x470 fs/namei.c:4016<br /> do_sys_openat2+0x17a/0x1e0 fs/open.c:1428<br /> do_sys_open fs/open.c:1443 [inline]<br /> __do_sys_openat fs/open.c:1459 [inline]<br /> __se_sys_openat fs/open.c:1454 [inline]<br /> __x64_sys_openat+0x175/0x210 fs/open.c:1454<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> -&gt; #1 ((pm_chain_head).rwsem){++++}-{4:4}:<br /> down_read+0x9a/0x330 kernel/locking/rwsem.c:1524<br /> blocking_notifier_call_chain_robust kerne<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/dwc_pcie: fix duplicate pci_dev devices<br /> <br /> During platform_device_register, wrongly using struct device<br /> pci_dev as platform_data caused a kmemdup copy of pci_dev. Worse<br /> still, accessing the duplicated device leads to list corruption as its<br /> mutex content (e.g., list, magic) remains the same as the original.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix hang while freeing sigtrap event<br /> <br /> Perf can hang while freeing a sigtrap event if a related deferred<br /> signal hadn&amp;#39;t managed to be sent before the file got closed:<br /> <br /> perf_event_overflow()<br /> task_work_add(perf_pending_task)<br /> <br /> fput()<br /> task_work_add(____fput())<br /> <br /> task_work_run()<br /> ____fput()<br /> perf_release()<br /> perf_event_release_kernel()<br /> _free_event()<br /> perf_pending_task_sync()<br /> task_work_cancel() -&gt; FAILED<br /> rcuwait_wait_event()<br /> <br /> Once task_work_run() is running, the list of pending callbacks is<br /> removed from the task_struct and from this point on task_work_cancel()<br /> can&amp;#39;t remove any pending and not yet started work items, hence the<br /> task_work_cancel() failure and the hang on rcuwait_wait_event().<br /> <br /> Task work could be changed to remove one work at a time, so a work<br /> running on the current task can always cancel a pending one, however<br /> the wait / wake design is still subject to inverted dependencies when<br /> remote targets are involved, as pictured by Oleg:<br /> <br /> T1 T2<br /> <br /> fd = perf_event_open(pid =&gt; T2-&gt;pid); fd = perf_event_open(pid =&gt; T1-&gt;pid);<br /> close(fd) close(fd)<br /> <br /> perf_event_overflow() perf_event_overflow()<br /> task_work_add(perf_pending_task) task_work_add(perf_pending_task)<br /> <br /> fput() fput()<br /> task_work_add(____fput()) task_work_add(____fput())<br /> <br /> task_work_run() task_work_run()<br /> ____fput() ____fput()<br /> perf_release() perf_release()<br /> perf_event_release_kernel() perf_event_release_kernel()<br /> _free_event() _free_event()<br /> perf_pending_task_sync() perf_pending_task_sync()<br /> rcuwait_wait_event() rcuwait_wait_event()<br /> <br /> Therefore the only option left is to acquire the event reference count<br /> upon queueing the perf task work and release it from the task work, just<br /> like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release")<br /> but without the leaks it fixed.<br /> <br /> Some adjustments are necessary to make it work:<br /> <br /> * A child event might dereference its parent upon freeing. Care must be<br /> taken to release the parent last.<br /> <br /> * Some places assuming the event doesn&amp;#39;t have any reference held and<br /> therefore can be freed right away must instead put the reference and<br /> let the reference counting to its job.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/cpu: Avoid running off the end of an AMD erratum table<br /> <br /> The NULL array terminator at the end of erratum_1386_microcode was<br /> removed during the switch from x86_cpu_desc to x86_cpu_id. This<br /> causes readers to run off the end of the array.<br /> <br /> Replace the NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix UAF in decryption with multichannel<br /> <br /> After commit f7025d861694 ("smb: client: allocate crypto only for<br /> primary server") and commit b0abcd65ec54 ("smb: client: fix UAF in<br /> async decryption"), the channels started reusing AEAD TFM from primary<br /> channel to perform synchronous decryption, but that can&amp;#39;t done as<br /> there could be multiple cifsd threads (one per channel) simultaneously<br /> accessing it to perform decryption.<br /> <br /> This fixes the following KASAN splat when running fstest generic/249<br /> with &amp;#39;vers=3.1.1,multichannel,max_channels=4,seal&amp;#39; against Windows<br /> Server 2022:<br /> <br /> BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110<br /> Read of size 8 at addr ffff8881046c18a0 by task cifsd/986<br /> CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1<br /> PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41<br /> 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5d/0x80<br /> print_report+0x156/0x528<br /> ? gf128mul_4k_lle+0xba/0x110<br /> ? __virt_addr_valid+0x145/0x300<br /> ? __phys_addr+0x46/0x90<br /> ? gf128mul_4k_lle+0xba/0x110<br /> kasan_report+0xdf/0x1a0<br /> ? gf128mul_4k_lle+0xba/0x110<br /> gf128mul_4k_lle+0xba/0x110<br /> ghash_update+0x189/0x210<br /> shash_ahash_update+0x295/0x370<br /> ? __pfx_shash_ahash_update+0x10/0x10<br /> ? __pfx_shash_ahash_update+0x10/0x10<br /> ? __pfx_extract_iter_to_sg+0x10/0x10<br /> ? ___kmalloc_large_node+0x10e/0x180<br /> ? __asan_memset+0x23/0x50<br /> crypto_ahash_update+0x3c/0xc0<br /> gcm_hash_assoc_remain_continue+0x93/0xc0<br /> crypt_message+0xe09/0xec0 [cifs]<br /> ? __pfx_crypt_message+0x10/0x10 [cifs]<br /> ? _raw_spin_unlock+0x23/0x40<br /> ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs]<br /> decrypt_raw_data+0x229/0x380 [cifs]<br /> ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]<br /> ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs]<br /> smb3_receive_transform+0x837/0xc80 [cifs]<br /> ? __pfx_smb3_receive_transform+0x10/0x10 [cifs]<br /> ? __pfx___might_resched+0x10/0x10<br /> ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs]<br /> cifs_demultiplex_thread+0x692/0x1570 [cifs]<br /> ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]<br /> ? rcu_is_watching+0x20/0x50<br /> ? rcu_lockdep_current_cpu_online+0x62/0xb0<br /> ? find_held_lock+0x32/0x90<br /> ? kvm_sched_clock_read+0x11/0x20<br /> ? local_clock_noinstr+0xd/0xd0<br /> ? trace_irq_enable.constprop.0+0xa8/0xe0<br /> ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]<br /> kthread+0x1fe/0x380<br /> ? kthread+0x10f/0x380<br /> ? __pfx_kthread+0x10/0x10<br /> ? local_clock_noinstr+0xd/0xd0<br /> ? ret_from_fork+0x1b/0x60<br /> ? local_clock+0x15/0x30<br /> ? lock_release+0x29b/0x390<br /> ? rcu_is_watching+0x20/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x60<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: ignore xattrs past end<br /> <br /> Once inside &amp;#39;ext4_xattr_inode_dec_ref_all&amp;#39; we should<br /> ignore xattrs entries past the &amp;#39;end&amp;#39; entry.<br /> <br /> This fixes the following KASAN reported issue:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90<br /> Read of size 4 at addr ffff888012c120c4 by task repro/2065<br /> <br /> CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x1fd/0x300<br /> ? tcp_gro_dev_warn+0x260/0x260<br /> ? _printk+0xc0/0x100<br /> ? read_lock_is_recursive+0x10/0x10<br /> ? irq_work_queue+0x72/0xf0<br /> ? __virt_addr_valid+0x17b/0x4b0<br /> print_address_description+0x78/0x390<br /> print_report+0x107/0x1f0<br /> ? __virt_addr_valid+0x17b/0x4b0<br /> ? __virt_addr_valid+0x3ff/0x4b0<br /> ? __phys_addr+0xb5/0x160<br /> ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90<br /> kasan_report+0xcc/0x100<br /> ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90<br /> ext4_xattr_inode_dec_ref_all+0xb8c/0xe90<br /> ? ext4_xattr_delete_inode+0xd30/0xd30<br /> ? __ext4_journal_ensure_credits+0x5f0/0x5f0<br /> ? __ext4_journal_ensure_credits+0x2b/0x5f0<br /> ? inode_update_timestamps+0x410/0x410<br /> ext4_xattr_delete_inode+0xb64/0xd30<br /> ? ext4_truncate+0xb70/0xdc0<br /> ? ext4_expand_extra_isize_ea+0x1d20/0x1d20<br /> ? __ext4_mark_inode_dirty+0x670/0x670<br /> ? ext4_journal_check_start+0x16f/0x240<br /> ? ext4_inode_is_fast_symlink+0x2f2/0x3a0<br /> ext4_evict_inode+0xc8c/0xff0<br /> ? ext4_inode_is_fast_symlink+0x3a0/0x3a0<br /> ? do_raw_spin_unlock+0x53/0x8a0<br /> ? ext4_inode_is_fast_symlink+0x3a0/0x3a0<br /> evict+0x4ac/0x950<br /> ? proc_nr_inodes+0x310/0x310<br /> ? trace_ext4_drop_inode+0xa2/0x220<br /> ? _raw_spin_unlock+0x1a/0x30<br /> ? iput+0x4cb/0x7e0<br /> do_unlinkat+0x495/0x7c0<br /> ? try_break_deleg+0x120/0x120<br /> ? 0xffffffff81000000<br /> ? __check_object_size+0x15a/0x210<br /> ? strncpy_from_user+0x13e/0x250<br /> ? getname_flags+0x1dc/0x530<br /> __x64_sys_unlinkat+0xc8/0xf0<br /> do_syscall_64+0x65/0x110<br /> entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> RIP: 0033:0x434ffd<br /> Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8<br /> RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107<br /> RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd<br /> RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005<br /> RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001<br /> R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001<br /> <br /> <br /> The buggy address belongs to the object at ffff888012c12000<br /> which belongs to the cache filp of size 360<br /> The buggy address is located 196 bytes inside of<br /> freed 360-byte region [ffff888012c12000, ffff888012c12168)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12<br /> head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> flags: 0x40(head|node=0|zone=0)<br /> page_type: f5(slab)<br /> raw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004<br /> raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000<br /> head: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004<br /> head: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000<br /> head: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000<br /> head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> &gt; ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc<br /> ffff888012c12180: fc fc fc fc fc fc fc fc fc<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Fix uninit-value access of imap allocated in the diMount() function<br /> <br /> syzbot reports that hex_dump_to_buffer is using uninit-value:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171<br /> hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171<br /> print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276<br /> diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876<br /> jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156<br /> evict+0x723/0xd10 fs/inode.c:796<br /> iput_final fs/inode.c:1946 [inline]<br /> iput+0x97b/0xdb0 fs/inode.c:1972<br /> txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367<br /> txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]<br /> jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733<br /> kthread+0x6b9/0xef0 kernel/kthread.c:464<br /> ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4121 [inline]<br /> slab_alloc_node mm/slub.c:4164 [inline]<br /> __kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320<br /> kmalloc_noprof include/linux/slab.h:901 [inline]<br /> diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105<br /> jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176<br /> jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523<br /> get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636<br /> get_tree_bdev+0x37/0x50 fs/super.c:1659<br /> jfs_get_tree+0x34/0x40 fs/jfs/super.c:635<br /> vfs_get_tree+0xb1/0x5a0 fs/super.c:1814<br /> do_new_mount+0x71f/0x15e0 fs/namespace.c:3560<br /> path_mount+0x742/0x1f10 fs/namespace.c:3887<br /> do_mount fs/namespace.c:3900 [inline]<br /> __do_sys_mount fs/namespace.c:4111 [inline]<br /> __se_sys_mount+0x71f/0x800 fs/namespace.c:4088<br /> __x64_sys_mount+0xe4/0x150 fs/namespace.c:4088<br /> x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> =====================================================<br /> <br /> The reason is that imap is not properly initialized after memory<br /> allocation. It will cause the snprintf() function to write uninitialized<br /> data into linebuf within hex_dump_to_buffer().<br /> <br /> Fix this by using kzalloc instead of kmalloc to clear its content at the<br /> beginning in diMount().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Prevent copying of nlink with value 0 from disk inode<br /> <br /> syzbot report a deadlock in diFree. [1]<br /> <br /> When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4,<br /> which does not match the mounted loop device, causing the mapping of the<br /> mounted loop device to be invalidated.<br /> <br /> When creating the directory and creating the inode of iag in diReadSpecial(),<br /> read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the<br /> metapage data it returns is corrupted, which causes the nlink value of 0 to be<br /> assigned to the iag inode when executing copy_from_dinode(), which ultimately<br /> causes a deadlock when entering diFree().<br /> <br /> To avoid this, first check the nlink value of dinode before setting iag inode.<br /> <br /> [1]<br /> WARNING: possible recursive locking detected<br /> 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted<br /> --------------------------------------------<br /> syz-executor301/5309 is trying to acquire lock:<br /> ffff888044548920 (&amp;(imap-&gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889<br /> <br /> but task is already holding lock:<br /> ffff888044548920 (&amp;(imap-&gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;(imap-&gt;im_aglock[index]));<br /> lock(&amp;(imap-&gt;im_aglock[index]));<br /> <br /> *** DEADLOCK ***<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 5 locks held by syz-executor301/5309:<br /> #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515<br /> #1: ffff88804755b390 (&amp;type-&gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]<br /> #1: ffff88804755b390 (&amp;type-&gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026<br /> #2: ffff888044548920 (&amp;(imap-&gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630<br /> #3: ffff888044548890 (&amp;imap-&gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]<br /> #3: ffff888044548890 (&amp;imap-&gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]<br /> #3: ffff888044548890 (&amp;imap-&gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669<br /> #4: ffff88804755a618 (&amp;jfs_ip-&gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]<br /> #4: ffff88804755a618 (&amp;jfs_ip-&gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]<br /> #4: ffff88804755a618 (&amp;jfs_ip-&gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669<br /> <br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037<br /> check_deadlock kernel/locking/lockdep.c:3089 [inline]<br /> validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891<br /> __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202<br /> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825<br /> __mutex_lock_common kernel/locking/mutex.c:608 [inline]<br /> __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752<br /> diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889<br /> jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156<br /> evict+0x4e8/0x9b0 fs/inode.c:725<br /> diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]<br /> duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022<br /> diNewIAG fs/jfs/jfs_imap.c:2597 [inline]<br /> diAllocExt fs/jfs/jfs_imap.c:1905 [inline]<br /> diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669<br /> diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590<br /> ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56<br /> jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225<br /> vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257<br /> do_mkdirat+0x264/0x3a0 fs/namei.c:4280<br /> __do_sys_mkdirat fs/namei.c:4295 [inline]<br /> __se_sys_mkdirat fs/namei.c:4293 [inline]<br /> __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293<br /> do_syscall_x64 arch/x86/en<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: add sanity check for agwidth in dbMount<br /> <br /> The width in dmapctl of the AG is zero, it trigger a divide error when<br /> calculating the control page level in dbAllocAG.<br /> <br /> To avoid this issue, add a check for agwidth in dbAllocAG.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()<br /> <br /> syzbot reports an UBSAN issue as below:<br /> <br /> ------------[ cut here ]------------<br /> UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10<br /> index 18446744073709550692 is out of range for type &amp;#39;__le32[5]&amp;#39; (aka &amp;#39;unsigned int[5]&amp;#39;)<br /> CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> ubsan_epilogue lib/ubsan.c:231 [inline]<br /> __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429<br /> get_nid fs/f2fs/node.h:381 [inline]<br /> f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181<br /> f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808<br /> f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836<br /> f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886<br /> f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093<br /> aio_write+0x56b/0x7c0 fs/aio.c:1633<br /> io_submit_one+0x8a7/0x18a0 fs/aio.c:2052<br /> __do_sys_io_submit fs/aio.c:2111 [inline]<br /> __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f238798cde9<br /> <br /> index 18446744073709550692 (decimal, unsigned long long)<br /> = 0xfffffffffffffc64 (hexadecimal, unsigned long long)<br /> = -924 (decimal, long long)<br /> <br /> In f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to<br /> access .i_nid[-924], it means both offset[0] and level should zero.<br /> <br /> The possible case should be in f2fs_do_truncate_blocks(), we try to<br /> truncate inode size to zero, however, dn.ofs_in_node is zero and<br /> dn.node_page is not an inode page, so it fails to truncate inode page,<br /> and then pass zeroed free_from to f2fs_truncate_inode_blocks(), result<br /> in this issue.<br /> <br /> if (dn.ofs_in_node || IS_INODE(dn.node_page)) {<br /> f2fs_truncate_data_blocks_range(&amp;dn, count);<br /> free_from += count;<br /> }<br /> <br /> I guess the reason why dn.node_page is not an inode page could be: there<br /> are multiple nat entries share the same node block address, once the node<br /> block address was reused, f2fs_get_node_page() may load a non-inode block.<br /> <br /> Let&amp;#39;s add a sanity check for such condition to avoid out-of-bounds access<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: vlan: don&amp;#39;t propagate flags on open<br /> <br /> With the device instance lock, there is now a possibility of a deadlock:<br /> <br /> [ 1.211455] ============================================<br /> [ 1.211571] WARNING: possible recursive locking detected<br /> [ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted<br /> [ 1.211823] --------------------------------------------<br /> [ 1.211936] ip/184 is trying to acquire lock:<br /> [ 1.212032] ffff8881024a4c30 (&amp;dev-&gt;lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0<br /> [ 1.212207]<br /> [ 1.212207] but task is already holding lock:<br /> [ 1.212332] ffff8881024a4c30 (&amp;dev-&gt;lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0<br /> [ 1.212487]<br /> [ 1.212487] other info that might help us debug this:<br /> [ 1.212626] Possible unsafe locking scenario:<br /> [ 1.212626]<br /> [ 1.212751] CPU0<br /> [ 1.212815] ----<br /> [ 1.212871] lock(&amp;dev-&gt;lock);<br /> [ 1.212944] lock(&amp;dev-&gt;lock);<br /> [ 1.213016]<br /> [ 1.213016] *** DEADLOCK ***<br /> [ 1.213016]<br /> [ 1.213143] May be due to missing lock nesting notation<br /> [ 1.213143]<br /> [ 1.213294] 3 locks held by ip/184:<br /> [ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0<br /> [ 1.213543] #1: ffffffff84e5fc70 (&amp;net-&gt;rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0<br /> [ 1.213727] #2: ffff8881024a4c30 (&amp;dev-&gt;lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0<br /> [ 1.213895]<br /> [ 1.213895] stack backtrace:<br /> [ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5<br /> [ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014<br /> [ 1.213994] Call Trace:<br /> [ 1.213995] <br /> [ 1.213996] dump_stack_lvl+0x8e/0xd0<br /> [ 1.214000] print_deadlock_bug+0x28b/0x2a0<br /> [ 1.214020] lock_acquire+0xea/0x2a0<br /> [ 1.214027] __mutex_lock+0xbf/0xd40<br /> [ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev-&gt;flags &amp; IFF_ALLMULTI<br /> [ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev<br /> [ 1.214042] __dev_open+0x145/0x270<br /> [ 1.214046] __dev_change_flags+0xb0/0x1e0<br /> [ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev<br /> [ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev-&gt;vlan_info<br /> [ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0<br /> [ 1.214058] notifier_call_chain+0x78/0x120<br /> [ 1.214062] netif_open+0x6d/0x90<br /> [ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0<br /> [ 1.214066] bond_enslave+0x64c/0x1230<br /> [ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0<br /> [ 1.214077] do_setlink+0x516/0x13b0<br /> [ 1.214094] rtnl_newlink+0xaba/0xb80<br /> [ 1.214132] rtnetlink_rcv_msg+0x440/0x490<br /> [ 1.214144] netlink_rcv_skb+0xeb/0x120<br /> [ 1.214150] netlink_unicast+0x1f9/0x320<br /> [ 1.214153] netlink_sendmsg+0x346/0x3f0<br /> [ 1.214157] __sock_sendmsg+0x86/0xb0<br /> [ 1.214160] ____sys_sendmsg+0x1c8/0x220<br /> [ 1.214164] ___sys_sendmsg+0x28f/0x2d0<br /> [ 1.214179] __x64_sys_sendmsg+0xef/0x140<br /> [ 1.214184] do_syscall_64+0xec/0x1d0<br /> [ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 1.214191] RIP: 0033:0x7f2d1b4a7e56<br /> <br /> Device setup:<br /> <br /> netdevsim0 (down)<br /> ^ ^<br /> bond netdevsim1.100@netdevsim1 allmulticast=on (down)<br /> <br /> When we enslave the lower device (netdevsim0) which has a vlan, we<br /> propagate vlan&amp;#39;s allmuti/promisc flags during ndo_open. This causes<br /> (re)locking on of the real_dev.<br /> <br /> Propagate allmulti/promisc on flags change, not on the open. There<br /> is a slight semantics change that vlans that are down now propagate<br /> the flags, but this seems unlikely to result in the real issues.<br /> <br /> Reproducer:<br /> <br /> echo 0 1 &gt; /sys/bus/netdevsim/new_device<br /> <br /> dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*)<br /> dev=$(echo $dev_path | rev | cut -d/ -f1 | rev)<br /> <br /> ip link set dev $dev name netdevsim0<br /> ip link set dev netdevsim0 up<br /> <br /> ip link add link netdevsim0 name netdevsim0.100 type vlan id 100<br /> ip link set dev netdevsim0.100 allm<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type<br /> <br /> The access to the PCI config space via pci_ops::read and pci_ops::write is<br /> a low-level hardware access. The functions can be accessed with disabled<br /> interrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this<br /> purpose.<br /> <br /> A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be<br /> acquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in<br /> the same context as the pci_lock.<br /> <br /> Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with<br /> interrupts disabled.<br /> <br /> This was reported as:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> Call Trace:<br /> rt_spin_lock+0x4e/0x130<br /> vmd_pci_read+0x8d/0x100 [vmd]<br /> pci_user_read_config_byte+0x6f/0xe0<br /> pci_read_config+0xfe/0x290<br /> sysfs_kf_bin_read+0x68/0x90<br /> <br /> [bigeasy: reword commit message]<br /> Tested-off-by: Luis Claudio R. Goncalves <br /> [kwilczynski: commit log]<br /> [bhelgaas: add back report info from<br /> https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]