Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid cycles in directory h-tree<br /> <br /> A maliciously corrupted filesystem can contain cycles in the h-tree<br /> stored inside a directory. That can easily lead to the kernel corrupting<br /> tree nodes that were already verified under its hands while doing a node<br /> split and consequently accessing unallocated memory. Fix the problem by<br /> verifying traversed block numbers are unique.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix a data-race in unix_dgram_peer_wake_me().<br /> <br /> unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`&amp;#39;s<br /> lock held and check if its receive queue is full. Here we need to<br /> use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise<br /> KCSAN will report a data-race.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: xfrm: unexport __init-annotated xfrm4_protocol_init()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it has been broken for a decade.<br /> <br /> Recently, I fixed modpost so it started to warn it again, then this<br /> showed up in linux-next builds.<br /> <br /> There are two ways to fix it:<br /> <br /> - Remove __init<br /> - Remove EXPORT_SYMBOL<br /> <br /> I chose the latter for this case because the only in-tree call-site,<br /> net/ipv4/xfrm4_policy.c is never compiled as modular.<br /> (CONFIG_XFRM is boolean)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list<br /> <br /> Every iteration of for_each_available_child_of_node() decrements<br /> the reference count of the previous node.<br /> when breaking early from a for_each_available_child_of_node() loop,<br /> we need to explicitly call of_node_put() on the gphy_fw_np.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug_on in ext4_writepages<br /> <br /> we got issue as follows:<br /> EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/ext4/inode.c:2708!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155<br /> RIP: 0010:ext4_writepages+0x1977/0x1c10<br /> RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000<br /> RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002<br /> RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000<br /> R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001<br /> R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028<br /> FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> do_writepages+0x130/0x3a0<br /> filemap_fdatawrite_wbc+0x83/0xa0<br /> filemap_flush+0xab/0xe0<br /> ext4_alloc_da_blocks+0x51/0x120<br /> __ext4_ioctl+0x1534/0x3210<br /> __x64_sys_ioctl+0x12c/0x170<br /> do_syscall_64+0x3b/0x90<br /> <br /> It may happen as follows:<br /> 1. write inline_data inode<br /> vfs_write<br /> new_sync_write<br /> ext4_file_write_iter<br /> ext4_buffered_write_iter<br /> generic_perform_write<br /> ext4_da_write_begin<br /> ext4_da_write_inline_data_begin -&gt; If inline data size too<br /> small will allocate block to write, then mapping will has<br /> dirty page<br /> ext4_da_convert_inline_data_to_extent -&gt;clear EXT4_STATE_MAY_INLINE_DATA<br /> 2. fallocate<br /> do_vfs_ioctl<br /> ioctl_preallocate<br /> vfs_fallocate<br /> ext4_fallocate<br /> ext4_convert_inline_data<br /> ext4_convert_inline_data_nolock<br /> ext4_map_blocks -&gt; fail will goto restore data<br /> ext4_restore_inline_data<br /> ext4_create_inline_data<br /> ext4_write_inline_data<br /> ext4_set_inode_state -&gt; set inode EXT4_STATE_MAY_INLINE_DATA<br /> 3. writepages<br /> __ext4_ioctl<br /> ext4_alloc_da_blocks<br /> filemap_flush<br /> filemap_fdatawrite_wbc<br /> do_writepages<br /> ext4_writepages<br /> if (ext4_has_inline_data(inode))<br /> BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))<br /> <br /> The root cause of this issue is we destory inline data until call<br /> ext4_writepages under delay allocation mode. But there maybe already<br /> convert from inline to extent. To solve this issue, we call<br /> filemap_flush first..

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state<br /> <br /> The EXT4_FC_REPLAY bit in sbi-&gt;s_mount_state is used to indicate that<br /> we are in the middle of replay the fast commit journal. This was<br /> actually a mistake, since the sbi-&gt;s_mount_info is initialized from<br /> es-&gt;s_state. Arguably s_mount_state is misleadingly named, but the<br /> name is historical --- s_mount_state and s_state dates back to ext2.<br /> <br /> What should have been used is the ext4_{set,clear,test}_mount_flag()<br /> inline functions, which sets EXT4_MF_* bits in sbi-&gt;s_mount_flags.<br /> <br /> The problem with using EXT4_FC_REPLAY is that a maliciously corrupted<br /> superblock could result in EXT4_FC_REPLAY getting set in<br /> s_mount_state. This bypasses some sanity checks, and this can trigger<br /> a BUG() in ext4_es_cache_extent(). As a easy-to-backport-fix, filter<br /> out the EXT4_FC_REPLAY bit for now. We should eventually transition<br /> away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix use-after-free in ext4_rename_dir_prepare<br /> <br /> We got issue as follows:<br /> EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue<br /> ext4_get_first_dir_block: bh-&gt;b_data=0xffff88810bee6000 len=34478<br /> ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh-&gt;b_data=0xffff88810bee6000<br /> ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae<br /> ==================================================================<br /> BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220<br /> Read of size 4 at addr ffff88810beee6ae by task rep/1895<br /> <br /> CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241<br /> Call Trace:<br /> dump_stack+0xbe/0xf9<br /> print_address_description.constprop.0+0x1e/0x220<br /> kasan_report.cold+0x37/0x7f<br /> ext4_rename_dir_prepare+0x152/0x220<br /> ext4_rename+0xf44/0x1ad0<br /> ext4_rename2+0x11c/0x170<br /> vfs_rename+0xa84/0x1440<br /> do_renameat2+0x683/0x8f0<br /> __x64_sys_renameat+0x53/0x60<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> RIP: 0033:0x7f45a6fc41c9<br /> RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9<br /> RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005<br /> RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080<br /> R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0<br /> R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> The buggy address belongs to the page:<br /> page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee<br /> flags: 0x200000000000000()<br /> raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000<br /> raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> &gt;ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ^<br /> ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ==================================================================<br /> Disabling lock debugging due to kernel taint<br /> ext4_rename_dir_prepare: [2] parent_de-&gt;inode=3537895424<br /> ext4_rename_dir_prepare: [3] dir=0xffff888124170140<br /> ext4_rename_dir_prepare: [4] ino=2<br /> ext4_rename_dir_prepare: ent-&gt;dir-&gt;i_ino=2 parent=-757071872<br /> <br /> Reason is first directory entry which &amp;#39;rec_len&amp;#39; is 34478, then will get illegal<br /> parent entry. Now, we do not check directory entry after read directory block<br /> in &amp;#39;ext4_get_first_dir_block&amp;#39;.<br /> To solve this issue, check directory entry in &amp;#39;ext4_get_first_dir_block&amp;#39;.<br /> <br /> [ Trigger an ext4_error() instead of just warning if the directory is<br /> missing a &amp;#39;.&amp;#39; or &amp;#39;..&amp;#39; entry. Also make sure we return an error code<br /> if the file system is corrupted. -TYT ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mdio: unexport __init-annotated mdio_bus_init()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it has been broken for a decade.<br /> <br /> Recently, I fixed modpost so it started to warn it again, then this<br /> showed up in linux-next builds.<br /> <br /> There are two ways to fix it:<br /> <br /> - Remove __init<br /> - Remove EXPORT_SYMBOL<br /> <br /> I chose the latter for this case because the only in-tree call-site,<br /> drivers/net/phy/phy_device.c is never compiled as modular.<br /> (CONFIG_PHYLIB is boolean)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: altera: Fix refcount leak in altera_tse_mdio_create<br /> <br /> Every iteration of for_each_child_of_node() decrements<br /> the reference count of the previous node.<br /> When break from a for_each_child_of_node() loop,<br /> we need to explicitly call of_node_put() on the child node when<br /> not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix warning in ext4_handle_inode_extension<br /> <br /> We got issue as follows:<br /> EXT4-fs error (device loop0) in ext4_reserve_inode_write:5741: Out of memory<br /> EXT4-fs error (device loop0): ext4_setattr:5462: inode #13: comm syz-executor.0: mark_inode_dirty error<br /> EXT4-fs error (device loop0) in ext4_setattr:5519: Out of memory<br /> EXT4-fs error (device loop0): ext4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can&amp;#39;t allocate blocks for non-extent mapped inodes with bigalloc<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 4361 at fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220<br /> Modules linked in:<br /> CPU: 1 PID: 4361 Comm: syz-executor.0 Not tainted 5.10.0+ #1<br /> RIP: 0010:ext4_file_write_iter+0x11c9/0x1220<br /> RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282<br /> RAX: ffffffff815a3379 RBX: 0000000000000000 RCX: 000000003b000000<br /> RDX: ffff924d81601000 RSI: 00000000000009cc RDI: 00000000000009cd<br /> RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f<br /> R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 000000000000000a<br /> R13: 0000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b<br /> FS: 00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> do_iter_readv_writev+0x2e5/0x360<br /> do_iter_write+0x112/0x4c0<br /> do_pwritev+0x1e5/0x390<br /> __x64_sys_pwritev2+0x7e/0xa0<br /> do_syscall_64+0x37/0x50<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Above issue may happen as follows:<br /> Assume<br /> inode.i_size=4096<br /> EXT4_I(inode)-&gt;i_disksize=4096<br /> <br /> step 1: set inode-&gt;i_isize = 8192<br /> ext4_setattr<br /> if (attr-&gt;ia_size != inode-&gt;i_size)<br /> EXT4_I(inode)-&gt;i_disksize = attr-&gt;ia_size;<br /> rc = ext4_mark_inode_dirty<br /> ext4_reserve_inode_write<br /> ext4_get_inode_loc<br /> __ext4_get_inode_loc<br /> sb_getblk --&gt; return -ENOMEM<br /> ...<br /> if (!error) -&gt;will not update i_size<br /> i_size_write(inode, attr-&gt;ia_size);<br /> Now:<br /> inode.i_size=4096<br /> EXT4_I(inode)-&gt;i_disksize=8192<br /> <br /> step 2: Direct write 4096 bytes<br /> ext4_file_write_iter<br /> ext4_dio_write_iter<br /> iomap_dio_rw -&gt;return error<br /> if (extend)<br /> ext4_handle_inode_extension<br /> WARN_ON_ONCE(i_size_read(inode) i_disksize);<br /> -&gt;Then trigger warning.<br /> <br /> To solve above issue, if mark inode dirty failed in ext4_setattr just<br /> set &amp;#39;EXT4_I(inode)-&gt;i_disksize&amp;#39; with old value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: E-Switch, pair only capable devices<br /> <br /> OFFLOADS paring using devcom is possible only on devices<br /> that support LAG. Filter based on lag capabilities.<br /> <br /> This fixes an issue where mlx5_get_next_phys_dev() was<br /> called without holding the interface lock.<br /> <br /> This issue was found when commit<br /> bc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices")<br /> added an assert that verifies the interface lock is held.<br /> <br /> WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]<br /> Modules linked in: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [last unloaded: mlx5_core]<br /> CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]<br /> Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff<br /> RSP: 0018:ffff88811bf47458 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001<br /> RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78<br /> RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437<br /> R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000<br /> R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428<br /> FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core]<br /> mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core]<br /> esw_offloads_enable+0x1153/0x1500 [mlx5_core]<br /> ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core]<br /> ? wait_for_completion_io_timeout+0x20/0x20<br /> ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core]<br /> mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core]<br /> ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core]<br /> ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core]<br /> ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core]<br /> ? __debugfs_create_file+0x260/0x3e0<br /> mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core]<br /> ? mutex_lock_io_nested+0x12c0/0x12c0<br /> ? esw_offloads_disable+0x250/0x250 [mlx5_core]<br /> ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470<br /> ? rcu_read_lock_sched_held+0x3f/0x70<br /> devlink_nl_cmd_eswitch_set_doit+0x217/0x620

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: Fix xarray node memory leak<br /> <br /> If xas_split_alloc() fails to allocate the necessary nodes to complete the<br /> xarray entry split, it sets the xa_state to -ENOMEM, which xas_nomem()<br /> then interprets as "Please allocate more memory", not as "Please free<br /> any unnecessary memory" (which was the intended outcome). It&amp;#39;s confusing<br /> to use xas_nomem() to free memory in this context, so call xas_destroy()<br /> instead.