Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix bad pointer dereference when ehandler kthread is invalid<br /> <br /> Commit 66a834d09293 ("scsi: core: Fix error handling of scsi_host_alloc()")<br /> changed the allocation logic to call put_device() to perform host cleanup<br /> with the assumption that IDA removal and stopping the kthread would<br /> properly be performed in scsi_host_dev_release(). However, in the unlikely<br /> case that the error handler thread fails to spawn, shost-&gt;ehandler is set<br /> to ERR_PTR(-ENOMEM).<br /> <br /> The error handler cleanup code in scsi_host_dev_release() will call<br /> kthread_stop() if shost-&gt;ehandler != NULL which will always be the case<br /> whether the kthread was successfully spawned or not. In the case that it<br /> failed to spawn this has the nasty side effect of trying to dereference an<br /> invalid pointer when kthread_stop() is called. The following splat provides<br /> an example of this behavior in the wild:<br /> <br /> scsi host11: error handler thread failed to spawn, error = -4<br /> Kernel attempted to read user page (10c) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x0000010c<br /> Faulting instruction address: 0xc00000000818e9a8<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region<br /> hash dm_log dm_mod fuse overlay squashfs loop<br /> CPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1<br /> NIP: c00000000818e9a8 LR: c0000000089846e8 CTR: 0000000000007ee8<br /> REGS: c000000037d12ea0 TRAP: 0300 Not tainted (5.13.0-rc7)<br /> MSR: 800000000280b033 &amp;lt;SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE&amp;gt; CR: 28228228<br /> XER: 20040001<br /> CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0<br /> GPR00: c0000000089846e8 c000000037d13140 c000000009cc1100 fffffffffffffffc<br /> GPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000<br /> GPR08: 0000000000000000 c000000037dc0000 0000000000000001 00000000fffff7ff<br /> GPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0<br /> GPR16: 0000000000001740 c0080000190d0000 c0080000190d1740 c000000009129288<br /> GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898<br /> GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 0000000000000000<br /> GPR28: c000000046b28280 0000000000000000 000000000000010c fffffffffffffffc<br /> NIP [c00000000818e9a8] kthread_stop+0x38/0x230<br /> LR [c0000000089846e8] scsi_host_dev_release+0x98/0x160<br /> Call Trace:<br /> [c000000033bb2c48] 0xc000000033bb2c48 (unreliable)<br /> [c0000000089846e8] scsi_host_dev_release+0x98/0x160<br /> [c00000000891e960] device_release+0x60/0x100<br /> [c0000000087e55c4] kobject_release+0x84/0x210<br /> [c00000000891ec78] put_device+0x28/0x40<br /> [c000000008984ea4] scsi_host_alloc+0x314/0x430<br /> [c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi]<br /> [c000000008110104] vio_bus_probe+0xa4/0x4b0<br /> [c00000000892a860] really_probe+0x140/0x680<br /> [c00000000892aefc] driver_probe_device+0x15c/0x200<br /> [c00000000892b63c] device_driver_attach+0xcc/0xe0<br /> [c00000000892b740] __driver_attach+0xf0/0x200<br /> [c000000008926f28] bus_for_each_dev+0xa8/0x130<br /> [c000000008929ce4] driver_attach+0x34/0x50<br /> [c000000008928fc0] bus_add_driver+0x1b0/0x300<br /> [c00000000892c798] driver_register+0x98/0x1a0<br /> [c00000000810eb60] __vio_register_driver+0x80/0xe0<br /> [c0080000190b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi]<br /> [c0000000080121d0] do_one_initcall+0x60/0x2d0<br /> [c000000008261abc] do_init_module+0x7c/0x320<br /> [c000000008265700] load_module+0x2350/0x25b0<br /> [c000000008265cb4] __do_sys_finit_module+0xd4/0x160<br /> [c000000008031110] system_call_exception+0x150/0x2d0<br /> [c00000000800d35c] system_call_common+0xec/0x278<br /> <br /> Fix this be nulling shost-&gt;ehandler when the kthread fails to spawn.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbmem: Do not delete the mode that is still in use<br /> <br /> The execution of fb_delete_videomode() is not based on the result of the<br /> previous fbcon_mode_deleted(). As a result, the mode is directly deleted,<br /> regardless of whether it is still in use, which may cause UAF.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in fb_mode_is_equal+0x36e/0x5e0 \<br /> drivers/video/fbdev/core/modedb.c:924<br /> Read of size 4 at addr ffff88807e0ddb1c by task syz-executor.0/18962<br /> <br /> CPU: 2 PID: 18962 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ...<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x137/0x1be lib/dump_stack.c:118<br /> print_address_description+0x6c/0x640 mm/kasan/report.c:385<br /> __kasan_report mm/kasan/report.c:545 [inline]<br /> kasan_report+0x13d/0x1e0 mm/kasan/report.c:562<br /> fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924<br /> fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon.c:2746<br /> fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975<br /> do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108<br /> vfs_ioctl fs/ioctl.c:48 [inline]<br /> __do_sys_ioctl fs/ioctl.c:753 [inline]<br /> __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739<br /> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Freed by task 18960:<br /> kasan_save_stack mm/kasan/common.c:48 [inline]<br /> kasan_set_track+0x3d/0x70 mm/kasan/common.c:56<br /> kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355<br /> __kasan_slab_free+0x108/0x140 mm/kasan/common.c:422<br /> slab_free_hook mm/slub.c:1541 [inline]<br /> slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574<br /> slab_free mm/slub.c:3139 [inline]<br /> kfree+0xca/0x3d0 mm/slub.c:4121<br /> fb_delete_videomode+0x56a/0x820 drivers/video/fbdev/core/modedb.c:1104<br /> fb_set_var+0x1f3/0xdb0 drivers/video/fbdev/core/fbmem.c:978<br /> do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108<br /> vfs_ioctl fs/ioctl.c:48 [inline]<br /> __do_sys_ioctl fs/ioctl.c:753 [inline]<br /> __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739<br /> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-core: explicitly clear ioctl input data<br /> <br /> As seen from a recent syzbot bug report, mistakes in the compat ioctl<br /> implementation can lead to uninitialized kernel stack data getting used<br /> as input for driver ioctl handlers.<br /> <br /> The reported bug is now fixed, but it&amp;#39;s possible that other related<br /> bugs are still present or get added in the future. As the drivers need<br /> to check user input already, the possible impact is fairly low, but it<br /> might still cause an information leak.<br /> <br /> To be on the safe side, always clear the entire ioctl buffer before<br /> calling the conversion handler functions that are meant to initialize<br /> them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: mmio: Fix use-after-free Read in kvm_vm_ioctl_unregister_coalesced_mmio<br /> <br /> BUG: KASAN: use-after-free in kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183<br /> Read of size 8 at addr ffff0000c03a2500 by task syz-executor083/4269<br /> <br /> CPU: 5 PID: 4269 Comm: syz-executor083 Not tainted 5.10.0 #7<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x2d0 arch/arm64/kernel/stacktrace.c:132<br /> show_stack+0x28/0x34 arch/arm64/kernel/stacktrace.c:196<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x110/0x164 lib/dump_stack.c:118<br /> print_address_description+0x78/0x5c8 mm/kasan/report.c:385<br /> __kasan_report mm/kasan/report.c:545 [inline]<br /> kasan_report+0x148/0x1e4 mm/kasan/report.c:562<br /> check_memory_region_inline mm/kasan/generic.c:183 [inline]<br /> __asan_load8+0xb4/0xbc mm/kasan/generic.c:252<br /> kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183<br /> kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755<br /> vfs_ioctl fs/ioctl.c:48 [inline]<br /> __do_sys_ioctl fs/ioctl.c:753 [inline]<br /> __se_sys_ioctl fs/ioctl.c:739 [inline]<br /> __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739<br /> __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]<br /> invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]<br /> el0_svc_common arch/arm64/kernel/syscall.c:158 [inline]<br /> do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220<br /> el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367<br /> el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383<br /> el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670<br /> <br /> Allocated by task 4269:<br /> stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121<br /> kasan_save_stack mm/kasan/common.c:48 [inline]<br /> kasan_set_track mm/kasan/common.c:56 [inline]<br /> __kasan_kmalloc+0xdc/0x120 mm/kasan/common.c:461<br /> kasan_kmalloc+0xc/0x14 mm/kasan/common.c:475<br /> kmem_cache_alloc_trace include/linux/slab.h:450 [inline]<br /> kmalloc include/linux/slab.h:552 [inline]<br /> kzalloc include/linux/slab.h:664 [inline]<br /> kvm_vm_ioctl_register_coalesced_mmio+0x78/0x1cc arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:146<br /> kvm_vm_ioctl+0x7e8/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3746<br /> vfs_ioctl fs/ioctl.c:48 [inline]<br /> __do_sys_ioctl fs/ioctl.c:753 [inline]<br /> __se_sys_ioctl fs/ioctl.c:739 [inline]<br /> __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739<br /> __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]<br /> invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]<br /> el0_svc_common arch/arm64/kernel/syscall.c:158 [inline]<br /> do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220<br /> el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367<br /> el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383<br /> el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670<br /> <br /> Freed by task 4269:<br /> stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121<br /> kasan_save_stack mm/kasan/common.c:48 [inline]<br /> kasan_set_track+0x38/0x6c mm/kasan/common.c:56<br /> kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:355<br /> __kasan_slab_free+0x124/0x150 mm/kasan/common.c:422<br /> kasan_slab_free+0x10/0x1c mm/kasan/common.c:431<br /> slab_free_hook mm/slub.c:1544 [inline]<br /> slab_free_freelist_hook mm/slub.c:1577 [inline]<br /> slab_free mm/slub.c:3142 [inline]<br /> kfree+0x104/0x38c mm/slub.c:4124<br /> coalesced_mmio_destructor+0x94/0xa4 arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:102<br /> kvm_iodevice_destructor include/kvm/iodev.h:61 [inline]<br /> kvm_io_bus_unregister_dev+0x248/0x280 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:4374<br /> kvm_vm_ioctl_unregister_coalesced_mmio+0x158/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:186<br /> kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755<br /> vfs_ioctl fs/ioctl.c:48 [inline]<br /> __do_sys_ioctl fs/ioctl.c:753 [inline]<br /> __se_sys_ioctl fs/ioctl.c:739 [inline]<br /> __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739<br /> __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]<br /> invoke_syscall arch/arm64/kernel/sys<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix possible UAF when remounting r/o a mmp-protected file system<br /> <br /> After commit 618f003199c6 ("ext4: fix memory leak in<br /> ext4_fill_super"), after the file system is remounted read-only, there<br /> is a race where the kmmpd thread can exit, causing sbi-&gt;s_mmp_tsk to<br /> point at freed memory, which the call to ext4_stop_mmpd() can trip<br /> over.<br /> <br /> Fix this by only allowing kmmpd() to exit when it is stopped via<br /> ext4_stop_mmpd().<br /> <br /> Bug-Report-Link:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm btree remove: assign new_root only when removal succeeds<br /> <br /> remove_raw() in dm_btree_remove() may fail due to IO read error<br /> (e.g. read the content of origin block fails during shadowing),<br /> and the value of shadow_spine::root is uninitialized, but<br /> the uninitialized value is still assign to new_root in the<br /> end of dm_btree_remove().<br /> <br /> For dm-thin, the value of pmd-&gt;details_root or pmd-&gt;root will become<br /> an uninitialized value, so if trying to read details_info tree again<br /> out-of-bound memory may occur as showed below:<br /> <br /> general protection fault, probably for non-canonical address 0x3fdcb14c8d7520<br /> CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6<br /> Hardware name: QEMU Standard PC<br /> RIP: 0010:metadata_ll_load_ie+0x14/0x30<br /> Call Trace:<br /> sm_metadata_count_is_more_than_one+0xb9/0xe0<br /> dm_tm_shadow_block+0x52/0x1c0<br /> shadow_step+0x59/0xf0<br /> remove_raw+0xb2/0x170<br /> dm_btree_remove+0xf4/0x1c0<br /> dm_pool_delete_thin_device+0xc3/0x140<br /> pool_message+0x218/0x2b0<br /> target_message+0x251/0x290<br /> ctl_ioctl+0x1c4/0x4d0<br /> dm_ctl_ioctl+0xe/0x20<br /> __x64_sys_ioctl+0x7b/0xb0<br /> do_syscall_64+0x40/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Fixing it by only assign new_root when removal succeeds

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix GPF in diFree<br /> <br /> Avoid passing inode with<br /> JFS_SBI(inode-&gt;i_sb)-&gt;ipimap == NULL to<br /> diFree()[1]. GFP will appear:<br /> <br /> struct inode *ipimap = JFS_SBI(ip-&gt;i_sb)-&gt;ipimap;<br /> struct inomap *imap = JFS_IP(ipimap)-&gt;i_imap;<br /> <br /> JFS_IP() will return invalid pointer when ipimap == NULL<br /> <br /> Call Trace:<br /> diFree+0x13d/0x2dc0 fs/jfs/jfs_imap.c:853 [1]<br /> jfs_evict_inode+0x2c9/0x370 fs/jfs/inode.c:154<br /> evict+0x2ed/0x750 fs/inode.c:578<br /> iput_final fs/inode.c:1654 [inline]<br /> iput.part.0+0x3fe/0x820 fs/inode.c:1680<br /> iput+0x58/0x70 fs/inode.c:1670

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/bpf: Fix detecting BPF atomic instructions<br /> <br /> Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other<br /> atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to<br /> distinguish instructions based on the immediate field. Existing JIT<br /> implementations were updated to check for the immediate field and to<br /> reject programs utilizing anything more than BPF_ADD (such as BPF_FETCH)<br /> in the immediate field.<br /> <br /> However, the check added to powerpc64 JIT did not look at the correct<br /> BPF instruction. Due to this, such programs would be accepted and<br /> incorrectly JIT&amp;#39;ed resulting in soft lockups, as seen with the atomic<br /> bounds test. Fix this by looking at the correct immediate value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arch_topology: Avoid use-after-free for scale_freq_data<br /> <br /> Currently topology_scale_freq_tick() (which gets called from<br /> scheduler_tick()) may end up using a pointer to "struct<br /> scale_freq_data", which was previously cleared by<br /> topology_clear_scale_freq_source(), as there is no protection in place<br /> here. The users of topology_clear_scale_freq_source() though needs a<br /> guarantee that the previously cleared scale_freq_data isn&amp;#39;t used<br /> anymore, so they can free the related resources.<br /> <br /> Since topology_scale_freq_tick() is called from scheduler tick, we don&amp;#39;t<br /> want to add locking in there. Use the RCU update mechanism instead<br /> (which is already used by the scheduler&amp;#39;s utilization update path) to<br /> guarantee race free updates here.<br /> <br /> synchronize_rcu() makes sure that all RCU critical sections that started<br /> before it is called, will finish before it returns. And so the callers<br /> of topology_clear_scale_freq_source() don&amp;#39;t need to worry about their<br /> callback getting called anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-blk: Fix memory leak among suspend/resume procedure<br /> <br /> The vblk-&gt;vqs should be freed before we call init_vqs()<br /> in virtblk_restore().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: fix acl memory leak of posix_acl_create()<br /> <br /> When looking into another nfs xfstests report, I found acl and<br /> default_acl in nfs3_proc_create() and nfs3_proc_mknod() error<br /> paths are possibly leaked. Fix them in advance.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: Fix possible use-after-free by calling del_timer_sync()<br /> <br /> This driver&amp;#39;s remove path calls del_timer(). However, that function<br /> does not wait until the timer handler finishes. This means that the<br /> timer handler may still be running after the driver&amp;#39;s remove function<br /> has finished, which would result in a use-after-free.<br /> <br /> Fix by calling del_timer_sync(), which makes sure the timer handler<br /> has finished, and unable to re-schedule itself.