Vulnerabilities

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/]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vf: Don&amp;#39;t try to trigger a full GT reset if VF<br /> <br /> VFs don&amp;#39;t have access to the GDRST(0x941c) register that driver<br /> uses to reset a GT. Attempt to trigger a reset using debugfs:<br /> <br /> $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset<br /> <br /> or due to a hang condition detected by the driver leads to:<br /> <br /> [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe]<br /> [ ] xe 0000:00:02.1: [drm] GT0: reset queued<br /> [ ] xe 0000:00:02.1: [drm] GT0: reset started<br /> [ ] ------------[ cut here ]------------<br /> [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0<br /> [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] Call Trace:<br /> [ ] <br /> [ ] ? show_regs+0x6c/0x80<br /> [ ] ? __warn+0x93/0x1c0<br /> [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] ? report_bug+0x182/0x1b0<br /> [ ] ? handle_bug+0x6e/0xb0<br /> [ ] ? exc_invalid_op+0x18/0x80<br /> [ ] ? asm_exc_invalid_op+0x1b/0x20<br /> [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe]<br /> [ ] ? __mutex_unlock_slowpath+0x41/0x2e0<br /> [ ] xe_mmio_write32+0x64/0x150 [xe]<br /> [ ] do_gt_reset+0x2f/0xa0 [xe]<br /> [ ] gt_reset_worker+0x14e/0x1e0 [xe]<br /> [ ] process_one_work+0x21c/0x740<br /> [ ] worker_thread+0x1db/0x3c0<br /> <br /> Fix that by sending H2G VF_RESET(0x5507) action instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: hfi: add a check to handle OOB in sfr region<br /> <br /> sfr-&gt;buf_size is in shared memory and can be modified by malicious user.<br /> OOB write is possible when the size is made higher than actual sfr data<br /> buffer. Cap the size to allocated size for such cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: hfi: add check to handle incorrect queue size<br /> <br /> qsize represents size of shared queued between driver and video<br /> firmware. Firmware can modify this value to an invalid large value. In<br /> such situation, empty_space will be bigger than the space actually<br /> available. Since new_wr_idx is not checked, so the following code will<br /> result in an OOB write.<br /> ...<br /> qsize = qhdr-&gt;q_size<br /> <br /> if (wr_idx &gt;= rd_idx)<br /> empty_space = qsize - (wr_idx - rd_idx)<br /> ....<br /> if (new_wr_idx

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: hfi_parser: add check to avoid out of bound access<br /> <br /> There is a possibility that init_codecs is invoked multiple times during<br /> manipulated payload from video firmware. In such case, if codecs_count<br /> can get incremented to value more than MAX_CODEC_NUM, there can be OOB<br /> access. Reset the count so that it always starts from beginning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: hfi_parser: refactor hfi packet parsing logic<br /> <br /> words_count denotes the number of words in total payload, while data<br /> points to payload of various property within it. When words_count<br /> reaches last word, data can access memory beyond the total payload. This<br /> can lead to OOB access. With this patch, the utility api for handling<br /> individual properties now returns the size of data consumed. Accordingly<br /> remaining bytes are calculated before parsing the payload, thereby<br /> eliminates the OOB access possibilities.