Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Validate buffer length while parsing index<br /> <br /> indx_read is called when we have some NTFS directory operations that<br /> need more information from the index buffers. This adds a sanity check<br /> to make sure the returned index buffer length is legit, or we may have<br /> some out-of-bound memory accesses.<br /> <br /> [ 560.897595] BUG: KASAN: slab-out-of-bounds in hdr_find_e.isra.0+0x10c/0x320<br /> [ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245<br /> [ 560.898760]<br /> [ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37<br /> [ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 560.900170] Call Trace:<br /> [ 560.900407] <br /> [ 560.900732] dump_stack_lvl+0x49/0x63<br /> [ 560.901108] print_report.cold+0xf5/0x689<br /> [ 560.901395] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 560.901716] kasan_report+0xa7/0x130<br /> [ 560.901950] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 560.902208] __asan_load2+0x68/0x90<br /> [ 560.902427] hdr_find_e.isra.0+0x10c/0x320<br /> [ 560.902846] ? cmp_uints+0xe0/0xe0<br /> [ 560.903363] ? cmp_sdh+0x90/0x90<br /> [ 560.903883] ? ntfs_bread_run+0x190/0x190<br /> [ 560.904196] ? rwsem_down_read_slowpath+0x750/0x750<br /> [ 560.904969] ? ntfs_fix_post_read+0xe0/0x130<br /> [ 560.905259] ? __kasan_check_write+0x14/0x20<br /> [ 560.905599] ? up_read+0x1a/0x90<br /> [ 560.905853] ? indx_read+0x22c/0x380<br /> [ 560.906096] indx_find+0x2ef/0x470<br /> [ 560.906352] ? indx_find_buffer+0x2d0/0x2d0<br /> [ 560.906692] ? __kasan_kmalloc+0x88/0xb0<br /> [ 560.906977] dir_search_u+0x196/0x2f0<br /> [ 560.907220] ? ntfs_nls_to_utf16+0x450/0x450<br /> [ 560.907464] ? __kasan_check_write+0x14/0x20<br /> [ 560.907747] ? mutex_lock+0x8f/0xe0<br /> [ 560.907970] ? __mutex_lock_slowpath+0x20/0x20<br /> [ 560.908214] ? kmem_cache_alloc+0x143/0x4b0<br /> [ 560.908459] ntfs_lookup+0xe0/0x100<br /> [ 560.908788] __lookup_slow+0x116/0x220<br /> [ 560.909050] ? lookup_fast+0x1b0/0x1b0<br /> [ 560.909309] ? lookup_fast+0x13f/0x1b0<br /> [ 560.909601] walk_component+0x187/0x230<br /> [ 560.909944] link_path_walk.part.0+0x3f0/0x660<br /> [ 560.910285] ? handle_lookup_down+0x90/0x90<br /> [ 560.910618] ? path_init+0x642/0x6e0<br /> [ 560.911084] ? percpu_counter_add_batch+0x6e/0xf0<br /> [ 560.912559] ? __alloc_file+0x114/0x170<br /> [ 560.913008] path_openat+0x19c/0x1d10<br /> [ 560.913419] ? getname_flags+0x73/0x2b0<br /> [ 560.913815] ? kasan_save_stack+0x3a/0x50<br /> [ 560.914125] ? kasan_save_stack+0x26/0x50<br /> [ 560.914542] ? __kasan_slab_alloc+0x6d/0x90<br /> [ 560.914924] ? kmem_cache_alloc+0x143/0x4b0<br /> [ 560.915339] ? getname_flags+0x73/0x2b0<br /> [ 560.915647] ? getname+0x12/0x20<br /> [ 560.916114] ? __x64_sys_open+0x4c/0x60<br /> [ 560.916460] ? path_lookupat.isra.0+0x230/0x230<br /> [ 560.916867] ? __isolate_free_page+0x2e0/0x2e0<br /> [ 560.917194] do_filp_open+0x15c/0x1f0<br /> [ 560.917448] ? may_open_dev+0x60/0x60<br /> [ 560.917696] ? expand_files+0xa4/0x3a0<br /> [ 560.917923] ? __kasan_check_write+0x14/0x20<br /> [ 560.918185] ? _raw_spin_lock+0x88/0xdb<br /> [ 560.918409] ? _raw_spin_lock_irqsave+0x100/0x100<br /> [ 560.918783] ? _find_next_bit+0x4a/0x130<br /> [ 560.919026] ? _raw_spin_unlock+0x19/0x40<br /> [ 560.919276] ? alloc_fd+0x14b/0x2d0<br /> [ 560.919635] do_sys_openat2+0x32a/0x4b0<br /> [ 560.920035] ? file_open_root+0x230/0x230<br /> [ 560.920336] ? __rcu_read_unlock+0x5b/0x280<br /> [ 560.920813] do_sys_open+0x99/0xf0<br /> [ 560.921208] ? filp_open+0x60/0x60<br /> [ 560.921482] ? exit_to_user_mode_prepare+0x49/0x180<br /> [ 560.921867] __x64_sys_open+0x4c/0x60<br /> [ 560.922128] do_syscall_64+0x3b/0x90<br /> [ 560.922369] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 560.923030] RIP: 0033:0x7f7dff2e4469<br /> [ 560.923681] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088<br /> [ 560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000002<br /> [ 560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469<br /> [ 560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI:<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Lag, fix failure to cancel delayed bond work<br /> <br /> Commit 0d4e8ed139d8 ("net/mlx5: Lag, avoid lockdep warnings")<br /> accidentally removed a call to cancel delayed bond work thus it may<br /> cause queued delay to expire and fall on an already destroyed work<br /> queue.<br /> <br /> Fix by restoring the call cancel_delayed_work_sync() before<br /> destroying the workqueue.<br /> <br /> This prevents call trace such as this:<br /> <br /> [ 329.230417] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 329.231444] #PF: supervisor write access in kernel mode<br /> [ 329.232233] #PF: error_code(0x0002) - not-present page<br /> [ 329.233007] PGD 0 P4D 0<br /> [ 329.233476] Oops: 0002 [#1] SMP<br /> [ 329.234012] CPU: 5 PID: 145 Comm: kworker/u20:4 Tainted: G OE 6.0.0-rc5_mlnx #1<br /> [ 329.235282] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 329.236868] Workqueue: mlx5_cmd_0000:08:00.1 cmd_work_handler [mlx5_core]<br /> [ 329.237886] RIP: 0010:_raw_spin_lock+0xc/0x20<br /> [ 329.238585] Code: f0 0f b1 17 75 02 f3 c3 89 c6 e9 6f 3c 5f ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 31 c0 ba 01 00 00 00 0f b1 17 75 02 f3 c3 89 c6 e9 45 3c 5f ff 0f 1f 44 00 00 0f 1f<br /> [ 329.241156] RSP: 0018:ffffc900001b0e98 EFLAGS: 00010046<br /> [ 329.241940] RAX: 0000000000000000 RBX: ffffffff82374ae0 RCX: 0000000000000000<br /> [ 329.242954] RDX: 0000000000000001 RSI: 0000000000000014 RDI: 0000000000000000<br /> [ 329.243974] RBP: ffff888106ccf000 R08: ffff8881004000c8 R09: ffff888100400000<br /> [ 329.244990] R10: 0000000000000000 R11: ffffffff826669f8 R12: 0000000000002000<br /> [ 329.246009] R13: 0000000000000005 R14: ffff888100aa7ce0 R15: ffff88852ca80000<br /> [ 329.247030] FS: 0000000000000000(0000) GS:ffff88852ca80000(0000) knlGS:0000000000000000<br /> [ 329.248260] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 329.249111] CR2: 0000000000000000 CR3: 000000016d675001 CR4: 0000000000770ee0<br /> [ 329.250133] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 329.251152] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 329.252176] PKRU: 55555554

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Validate the box size for the snooped cursor<br /> <br /> Invalid userspace dma surface copies could potentially overflow<br /> the memcpy from the surface to the snooped image leading to crashes.<br /> To fix it the dimensions of the copybox have to be validated<br /> against the expected size of the snooped cursor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: ssdt: Don&amp;#39;t free memory if ACPI table was loaded successfully<br /> <br /> Amadeusz reports KASAN use-after-free errors introduced by commit<br /> 3881ee0b1edc ("efi: avoid efivars layer when loading SSDTs from<br /> variables"). The problem appears to be that the memory that holds the<br /> new ACPI table is now freed unconditionally, instead of only when the<br /> ACPI core reported a failure to load the table.<br /> <br /> So let&amp;#39;s fix this, by omitting the kfree() on success.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8173: Enable IRQ when pdata is ready<br /> <br /> If the device does not come straight from reset, we might receive an IRQ<br /> before we are ready to handle it.<br /> <br /> <br /> [ 2.334737] Unable to handle kernel read from unreadable memory at virtual address 00000000000001e4<br /> [ 2.522601] Call trace:<br /> [ 2.525040] regmap_read+0x1c/0x80<br /> [ 2.528434] mt8173_afe_irq_handler+0x40/0xf0<br /> ...<br /> [ 2.598921] start_kernel+0x338/0x42c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hinic: fix memory leak when reading function table<br /> <br /> When the input parameter idx meets the expected case option in<br /> hinic_dbg_get_func_table(), read_data is not released. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/hdmi: fix memory corruption with too many bridges<br /> <br /> Add the missing sanity check on the bridge counter to avoid corrupting<br /> data beyond the fixed-sized bridge array in case there are ever more<br /> than eight bridges.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502670/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid crash when inline data creation follows DIO write<br /> <br /> When inode is created and written to using direct IO, there is nothing<br /> to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets<br /> truncated later to say 1 byte and written using normal write, we will<br /> try to store the data as inline data. This confuses the code later<br /> because the inode now has both normal block and inline data allocated<br /> and the confusion manifests for example as:<br /> <br /> kernel BUG at fs/ext4/inode.c:2721!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014<br /> RIP: 0010:ext4_writepages+0x363d/0x3660<br /> RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293<br /> RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180<br /> RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000<br /> RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b<br /> R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128<br /> R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001<br /> FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0<br /> Call Trace:<br /> <br /> do_writepages+0x397/0x640<br /> filemap_fdatawrite_wbc+0x151/0x1b0<br /> file_write_and_wait_range+0x1c9/0x2b0<br /> ext4_sync_file+0x19e/0xa00<br /> vfs_fsync_range+0x17b/0x190<br /> ext4_buffered_write_iter+0x488/0x530<br /> ext4_file_write_iter+0x449/0x1b90<br /> vfs_write+0xbcd/0xf40<br /> ksys_write+0x198/0x2c0<br /> __x64_sys_write+0x7b/0x90<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> <br /> Fix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing<br /> direct IO write to a file.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t set up encryption key during jbd2 transaction<br /> <br /> Commit a80f7fcf1867 ("ext4: fixup ext4_fc_track_* functions&amp;#39; signature")<br /> extended the scope of the transaction in ext4_unlink() too far, making<br /> it include the call to ext4_find_entry(). However, ext4_find_entry()<br /> can deadlock when called from within a transaction because it may need<br /> to set up the directory&amp;#39;s encryption key.<br /> <br /> Fix this by restoring the transaction to its original scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: fix possible memleak when register &amp;#39;hctx&amp;#39; failed<br /> <br /> There&amp;#39;s issue as follows when do fault injection test:<br /> unreferenced object 0xffff888132a9f400 (size 512):<br /> comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2....<br /> 08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............<br /> backtrace:<br /> [] kmalloc_node_trace+0x22/0xa0<br /> [] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0<br /> [] blk_mq_realloc_hw_ctxs+0x1e6/0x230<br /> [] blk_mq_init_allocated_queue+0x27e/0x910<br /> [] __blk_mq_alloc_disk+0x67/0xf0<br /> [] 0xffffffffa2ad310f<br /> [] 0xffffffffa2af824a<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x3006/0x3390<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Fault injection context as follows:<br /> kobject_add<br /> blk_mq_register_hctx<br /> blk_mq_sysfs_register<br /> blk_register_queue<br /> device_add_disk<br /> null_add_dev.part.0 [null_blk]<br /> <br /> As &amp;#39;blk_mq_register_hctx&amp;#39; may already add some objects when failed halfway,<br /> but there isn&amp;#39;t do fallback, caller don&amp;#39;t know which objects add failed.<br /> To solve above issue just do fallback when add objects failed halfway in<br /> &amp;#39;blk_mq_register_hctx&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernfs: fix use-after-free in __kernfs_remove<br /> <br /> Syzkaller managed to trigger concurrent calls to<br /> kernfs_remove_by_name_ns() for the same file resulting in<br /> a KASAN detected use-after-free. The race occurs when the root<br /> node is freed during kernfs_drain().<br /> <br /> To prevent this acquire an additional reference for the root<br /> of the tree that is removed before calling __kernfs_remove().<br /> <br /> Found by syzkaller with the following reproducer (slab_nomerge is<br /> required):<br /> <br /> syz_mount_image$ext4(0x0, &amp;(0x7f0000000100)=&amp;#39;./file0\x00&amp;#39;, 0x100000, 0x0, 0x0, 0x0, 0x0)<br /> r0 = openat(0xffffffffffffff9c, &amp;(0x7f0000000080)=&amp;#39;/proc/self/exe\x00&amp;#39;, 0x0, 0x0)<br /> close(r0)<br /> pipe2(&amp;(0x7f0000000140)={0xffffffffffffffff, 0xffffffffffffffff}, 0x800)<br /> mount$9p_fd(0x0, &amp;(0x7f0000000040)=&amp;#39;./file0\x00&amp;#39;, &amp;(0x7f00000000c0), 0x408, &amp;(0x7f0000000280)={&amp;#39;trans=fd,&amp;#39;, {&amp;#39;rfdno&amp;#39;, 0x3d, r0}, 0x2c, {&amp;#39;wfdno&amp;#39;, 0x3d, r1}, 0x2c, {[{@cache_loose}, {@mmap}, {@loose}, {@loose}, {@mmap}], [{@mask={&amp;#39;mask&amp;#39;, 0x3d, &amp;#39;^MAY_EXEC&amp;#39;}}, {@fsmagic={&amp;#39;fsmagic&amp;#39;, 0x3d, 0x10001}}, {@dont_hash}]}})<br /> <br /> Sample report:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline]<br /> BUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]<br /> BUG: KASAN: use-after-free in __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369<br /> Read of size 2 at addr ffff8880088807f0 by task syz-executor.2/857<br /> <br /> CPU: 0 PID: 857 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:317 [inline]<br /> print_report.cold+0x5e/0x5e5 mm/kasan/report.c:433<br /> kasan_report+0xa3/0x130 mm/kasan/report.c:495<br /> kernfs_type include/linux/kernfs.h:335 [inline]<br /> kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline]<br /> __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369<br /> __kernfs_remove fs/kernfs/dir.c:1356 [inline]<br /> kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589<br /> sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943<br /> __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899<br /> create_cache mm/slab_common.c:229 [inline]<br /> kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335<br /> p9_client_create+0xd4d/0x1190 net/9p/client.c:993<br /> v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408<br /> v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126<br /> legacy_get_tree+0xf1/0x200 fs/fs_context.c:610<br /> vfs_get_tree+0x85/0x2e0 fs/super.c:1530<br /> do_new_mount fs/namespace.c:3040 [inline]<br /> path_mount+0x675/0x1d00 fs/namespace.c:3370<br /> do_mount fs/namespace.c:3383 [inline]<br /> __do_sys_mount fs/namespace.c:3591 [inline]<br /> __se_sys_mount fs/namespace.c:3568 [inline]<br /> __x64_sys_mount+0x282/0x300 fs/namespace.c:3568<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f725f983aed<br /> Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5<br /> RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed<br /> RDX: 00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000<br /> RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000<br /> R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000006 R14: 00007f725faa3f80 R15: 00007f725f0d7000<br /> <br /> <br /> Allocated by task 855:<br /> kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38<br /> kasan_set_track mm/kasan/common.c:45 [inline]<br /> set_alloc_info mm/kasan/common.c:437 [inline]<br /> __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:470<br /> kasan_slab_alloc include/linux/kasan.h:224 [inline]<br /> slab_post_alloc_hook mm/slab.h:7<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev()<br /> <br /> dev_set_name() in soundbus_add_one() allocates memory for name, it need be<br /> freed when of_device_register() fails, call soundbus_dev_put() to give up<br /> the reference that hold in device_initialize(), so that it can be freed in<br /> kobject_cleanup() when the refcount hit to 0. And other resources are also<br /> freed in i2sbus_release_dev(), so it can return 0 directly.