Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: common: usb-conn-gpio: fix NULL pointer dereference of charger<br /> <br /> When power on system with OTG cable, IDDIG&amp;#39;s interrupt arises before<br /> the charger registration, it will cause a NULL pointer dereference,<br /> fix the issue by registering the power supply before requesting<br /> IDDIG/VBUS irq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usx2y: Don&amp;#39;t call free_pages_exact() with NULL address<br /> <br /> Unlike some other functions, we can&amp;#39;t pass NULL pointer to<br /> free_pages_exact(). Add a proper NULL check for avoiding possible<br /> Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: alcor_pci: fix null-ptr-deref when there is no PCI bridge<br /> <br /> There is an issue with the ASPM(optional) capability checking function.<br /> A device might be attached to root complex directly, in this case,<br /> bus-&gt;self(bridge) will be NULL, thus priv-&gt;parent_pdev is NULL.<br /> Since alcor_pci_init_check_aspm(priv-&gt;parent_pdev) checks the PCI link&amp;#39;s<br /> ASPM capability and populate parent_cap_off, which will be used later by<br /> alcor_pci_aspm_ctrl() to dynamically turn on/off device, what we can do<br /> here is to avoid checking the capability if we are on the root complex.<br /> This will make pdev_cap_off 0 and alcor_pci_aspm_ctrl() will simply<br /> return when bring called, effectively disable ASPM for the device.<br /> <br /> [ 1.246492] BUG: kernel NULL pointer dereference, address: 00000000000000c0<br /> [ 1.248731] RIP: 0010:pci_read_config_byte+0x5/0x40<br /> [ 1.253998] Call Trace:<br /> [ 1.254131] ? alcor_pci_find_cap_offset.isra.0+0x3a/0x100 [alcor_pci]<br /> [ 1.254476] alcor_pci_probe+0x169/0x2d5 [alcor_pci]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc/libmasm/module: Fix two use after free in ibmasm_init_one<br /> <br /> In ibmasm_init_one, it calls ibmasm_init_remote_input_dev().<br /> Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are<br /> allocated by input_allocate_device(), and assigned to<br /> sp-&gt;remote.mouse_dev and sp-&gt;remote.keybd_dev respectively.<br /> <br /> In the err_free_devices error branch of ibmasm_init_one,<br /> mouse_dev and keybd_dev are freed by input_free_device(), and return<br /> error. Then the execution runs into error_send_message error branch<br /> of ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called<br /> to unregister the freed sp-&gt;remote.mouse_dev and sp-&gt;remote.keybd_dev.<br /> <br /> My patch add a "error_init_remote" label to handle the error of<br /> ibmasm_init_remote_input_dev(), to avoid the uaf bugs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances<br /> <br /> As syzbot reported, there is an use-after-free issue during f2fs recovery:<br /> <br /> Use-after-free write at 0xffff88823bc16040 (in kfence-#10):<br /> kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486<br /> f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869<br /> f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945<br /> mount_bdev+0x26c/0x3a0 fs/super.c:1367<br /> legacy_get_tree+0xea/0x180 fs/fs_context.c:592<br /> vfs_get_tree+0x86/0x270 fs/super.c:1497<br /> do_new_mount fs/namespace.c:2905 [inline]<br /> path_mount+0x196f/0x2be0 fs/namespace.c:3235<br /> do_mount fs/namespace.c:3248 [inline]<br /> __do_sys_mount fs/namespace.c:3456 [inline]<br /> __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433<br /> do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root cause is multi f2fs filesystem instances can race on accessing<br /> global fsync_entry_slab pointer, result in use-after-free issue of slab<br /> cache, fixes to init/destroy this slab cache only once during module<br /> init/destroy procedure to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smackfs: restrict bytes count in smk_set_cipso()<br /> <br /> Oops, I failed to update subject line.<br /> <br /> From 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001<br /> Date: Mon, 12 Apr 2021 22:25:06 +0900<br /> Subject: [PATCH] smackfs: restrict bytes count in smk_set_cipso()<br /> <br /> Commit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write<br /> functions") missed that count &gt; SMK_CIPSOMAX check applies to only<br /> format == SMK_FIXED24_FMT case.

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