Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: core: fix invalid port index for parent device<br /> <br /> In a commit 24b7f8e5cd65 ("firewire: core: use helper functions for self<br /> ID sequence"), the enumeration over self ID sequence was refactored with<br /> some helper functions with KUnit tests. These helper functions are<br /> guaranteed to work expectedly by the KUnit tests, however their application<br /> includes a mistake to assign invalid value to the index of port connected<br /> to parent device.<br /> <br /> This bug affects the case that any extra node devices which has three or<br /> more ports are connected to 1394 OHCI controller. In the case, the path<br /> to update the tree cache could hits WARN_ON(), and gets general protection<br /> fault due to the access to invalid address computed by the invalid value.<br /> <br /> This commit fixes the bug to assign correct port index.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Unregister redistributor for failed vCPU creation<br /> <br /> Alex reports that syzkaller has managed to trigger a use-after-free when<br /> tearing down a VM:<br /> <br /> BUG: KASAN: slab-use-after-free in kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769<br /> Read of size 8 at addr ffffff801c6890d0 by task syz.3.2219/10758<br /> <br /> CPU: 3 UID: 0 PID: 10758 Comm: syz.3.2219 Not tainted 6.11.0-rc6-dirty #64<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0x17c/0x1a8 arch/arm64/kernel/stacktrace.c:317<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:324<br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x94/0xc0 lib/dump_stack.c:119<br /> print_report+0x144/0x7a4 mm/kasan/report.c:377<br /> kasan_report+0xcc/0x128 mm/kasan/report.c:601<br /> __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381<br /> kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769<br /> kvm_vm_release+0x4c/0x60 virt/kvm/kvm_main.c:1409<br /> __fput+0x198/0x71c fs/file_table.c:422<br /> ____fput+0x20/0x30 fs/file_table.c:450<br /> task_work_run+0x1cc/0x23c kernel/task_work.c:228<br /> do_notify_resume+0x144/0x1a0 include/linux/resume_user_mode.h:50<br /> el0_svc+0x64/0x68 arch/arm64/kernel/entry-common.c:169<br /> el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598<br /> <br /> Upon closer inspection, it appears that we do not properly tear down the<br /> MMIO registration for a vCPU that fails creation late in the game, e.g.<br /> a vCPU w/ the same ID already exists in the VM.<br /> <br /> It is important to consider the context of commit that introduced this bug<br /> by moving the unregistration out of __kvm_vgic_vcpu_destroy(). That<br /> change correctly sought to avoid an srcu v. config_lock inversion by<br /> breaking up the vCPU teardown into two parts, one guarded by the<br /> config_lock.<br /> <br /> Fix the use-after-free while avoiding lock inversion by adding a<br /> special-cased unregistration to __kvm_vgic_vcpu_destroy(). This is safe<br /> because failed vCPUs are torn down outside of the config_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject ro-&gt;rw reconfiguration if there are hard ro requirements<br /> <br /> [BUG]<br /> Syzbot reports the following crash:<br /> <br /> BTRFS info (device loop0 state MCS): disabling free space tree<br /> BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1)<br /> BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [inline]<br /> RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041<br /> Call Trace:<br /> <br /> btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530<br /> btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312<br /> btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012<br /> btrfs_remount_rw fs/btrfs/super.c:1309 [inline]<br /> btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534<br /> btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [inline]<br /> btrfs_get_tree_subvol fs/btrfs/super.c:2079 [inline]<br /> btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115<br /> vfs_get_tree+0x90/0x2b0 fs/super.c:1800<br /> do_new_mount+0x2be/0xb40 fs/namespace.c:3472<br /> do_mount fs/namespace.c:3812 [inline]<br /> __do_sys_mount fs/namespace.c:4020 [inline]<br /> __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997<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 /> <br /> [CAUSE]<br /> To support mounting different subvolume with different RO/RW flags for<br /> the new mount APIs, btrfs introduced two workaround to support this feature:<br /> <br /> - Skip mount option/feature checks if we are mounting a different<br /> subvolume<br /> <br /> - Reconfigure the fs to RW if the initial mount is RO<br /> <br /> Combining these two, we can have the following sequence:<br /> <br /> - Mount the fs ro,rescue=all,clear_cache,space_cache=v1<br /> rescue=all will mark the fs as hard read-only, so no v2 cache clearing<br /> will happen.<br /> <br /> - Mount a subvolume rw of the same fs.<br /> We go into btrfs_get_tree_subvol(), but fc_mount() returns EBUSY<br /> because our new fc is RW, different from the original fs.<br /> <br /> Now we enter btrfs_reconfigure_for_mount(), which switches the RO flag<br /> first so that we can grab the existing fs_info.<br /> Then we reconfigure the fs to RW.<br /> <br /> - During reconfiguration, option/features check is skipped<br /> This means we will restart the v2 cache clearing, and convert back to<br /> v1 cache.<br /> This will trigger fs writes, and since the original fs has "rescue=all"<br /> option, it skips the csum tree read.<br /> <br /> And eventually causing NULL pointer dereference in super block<br /> writeback.<br /> <br /> [FIX]<br /> For reconfiguration caused by different subvolume RO/RW flags, ensure we<br /> always run btrfs_check_options() to ensure we have proper hard RO<br /> requirements met.<br /> <br /> In fact the function btrfs_check_options() doesn&amp;#39;t really do many<br /> complex checks, but hard RO requirement and some feature dependency<br /> checks, thus there is no special reason not to do the check for mount<br /> reconfiguration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix warning when destroy &amp;#39;cifs_io_request_pool&amp;#39;<br /> <br /> There&amp;#39;s a issue as follows:<br /> WARNING: CPU: 1 PID: 27826 at mm/slub.c:4698 free_large_kmalloc+0xac/0xe0<br /> RIP: 0010:free_large_kmalloc+0xac/0xe0<br /> Call Trace:<br /> <br /> ? __warn+0xea/0x330<br /> mempool_destroy+0x13f/0x1d0<br /> init_cifs+0xa50/0xff0 [cifs]<br /> do_one_initcall+0xdc/0x550<br /> do_init_module+0x22d/0x6b0<br /> load_module+0x4e96/0x5ff0<br /> init_module_from_file+0xcd/0x130<br /> idempotent_init_module+0x330/0x620<br /> __x64_sys_finit_module+0xb3/0x110<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Obviously, &amp;#39;cifs_io_request_pool&amp;#39; is not created by mempool_create().<br /> So just use mempool_exit() to revert &amp;#39;cifs_io_request_pool&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too<br /> <br /> Stuart Hayhurst has found that both at bootup and fullscreen VA-API video<br /> is leading to black screens for around 1 second and kernel WARNING [1] traces<br /> when calling dmub_psr_enable() with Parade 08-01 TCON.<br /> <br /> These symptoms all go away with PSR-SU disabled for this TCON, so disable<br /> it for now while DMUB traces [2] from the failure can be analyzed and the failure<br /> state properly root caused.<br /> <br /> (cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: fix one more kernel-infoleak in algo dumping<br /> <br /> During fuzz testing, the following issue was discovered:<br /> <br /> BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30<br /> _copy_to_iter+0x598/0x2a30<br /> __skb_datagram_iter+0x168/0x1060<br /> skb_copy_datagram_iter+0x5b/0x220<br /> netlink_recvmsg+0x362/0x1700<br /> sock_recvmsg+0x2dc/0x390<br /> __sys_recvfrom+0x381/0x6d0<br /> __x64_sys_recvfrom+0x130/0x200<br /> x64_sys_call+0x32c8/0x3cc0<br /> do_syscall_64+0xd8/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x79/0x81<br /> <br /> Uninit was stored to memory at:<br /> copy_to_user_state_extra+0xcc1/0x1e00<br /> dump_one_state+0x28c/0x5f0<br /> xfrm_state_walk+0x548/0x11e0<br /> xfrm_dump_sa+0x1e0/0x840<br /> netlink_dump+0x943/0x1c40<br /> __netlink_dump_start+0x746/0xdb0<br /> xfrm_user_rcv_msg+0x429/0xc00<br /> netlink_rcv_skb+0x613/0x780<br /> xfrm_netlink_rcv+0x77/0xc0<br /> netlink_unicast+0xe90/0x1280<br /> netlink_sendmsg+0x126d/0x1490<br /> __sock_sendmsg+0x332/0x3d0<br /> ____sys_sendmsg+0x863/0xc30<br /> ___sys_sendmsg+0x285/0x3e0<br /> __x64_sys_sendmsg+0x2d6/0x560<br /> x64_sys_call+0x1316/0x3cc0<br /> do_syscall_64+0xd8/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x79/0x81<br /> <br /> Uninit was created at:<br /> __kmalloc+0x571/0xd30<br /> attach_auth+0x106/0x3e0<br /> xfrm_add_sa+0x2aa0/0x4230<br /> xfrm_user_rcv_msg+0x832/0xc00<br /> netlink_rcv_skb+0x613/0x780<br /> xfrm_netlink_rcv+0x77/0xc0<br /> netlink_unicast+0xe90/0x1280<br /> netlink_sendmsg+0x126d/0x1490<br /> __sock_sendmsg+0x332/0x3d0<br /> ____sys_sendmsg+0x863/0xc30<br /> ___sys_sendmsg+0x285/0x3e0<br /> __x64_sys_sendmsg+0x2d6/0x560<br /> x64_sys_call+0x1316/0x3cc0<br /> do_syscall_64+0xd8/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x79/0x81<br /> <br /> Bytes 328-379 of 732 are uninitialized<br /> Memory access of size 732 starts at ffff88800e18e000<br /> Data copied to user address 00007ff30f48aff0<br /> <br /> CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> <br /> Fixes copying of xfrm algorithms where some random<br /> data of the structure fields can end up in userspace.<br /> Padding in structures may be filled with random (possibly sensitve)<br /> data and should never be given directly to user-space.<br /> <br /> A similar issue was resolved in the commit<br /> 8222d5910dae ("xfrm: Zero padding when dumping algos and encap")<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory<br /> <br /> Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits<br /> 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn&amp;#39;t<br /> enforce 32-byte alignment of nCR3.<br /> <br /> In the absolute worst case scenario, failure to ignore bits 4:0 can result<br /> in an out-of-bounds read, e.g. if the target page is at the end of a<br /> memslot, and the VMM isn&amp;#39;t using guard pages.<br /> <br /> Per the APM:<br /> <br /> The CR3 register points to the base address of the page-directory-pointer<br /> table. The page-directory-pointer table is aligned on a 32-byte boundary,<br /> with the low 5 address bits 4:0 assumed to be 0.<br /> <br /> And the SDM&amp;#39;s much more explicit:<br /> <br /> 4:0 Ignored<br /> <br /> Note, KVM gets this right when loading PDPTRs, it&amp;#39;s only the nSVM flow<br /> that is broken.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix kernel bug due to missing clearing of buffer delay flag<br /> <br /> Syzbot reported that after nilfs2 reads a corrupted file system image<br /> and degrades to read-only, the BUG_ON check for the buffer delay flag<br /> in submit_bh_wbc() may fail, causing a kernel bug.<br /> <br /> This is because the buffer delay flag is not cleared when clearing the<br /> buffer state flags to discard a page/folio or a buffer head. So, fix<br /> this.<br /> <br /> This became necessary when the use of nilfs2&amp;#39;s own page clear routine<br /> was expanded. This state inconsistency does not occur if the buffer<br /> is written normally by log writing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd: Guard against bad data for ATIF ACPI method<br /> <br /> If a BIOS provides bad data in response to an ATIF method call<br /> this causes a NULL pointer dereference in the caller.<br /> <br /> ```<br /> ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))<br /> ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)<br /> ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))<br /> ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))<br /> ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)<br /> ? exc_page_fault (arch/x86/mm/fault.c:1542)<br /> ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)<br /> ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu<br /> ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu<br /> ```<br /> <br /> It has been encountered on at least one system, so guard for it.<br /> <br /> (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: dummy-hcd: Fix "task hung" problem<br /> <br /> The syzbot fuzzer has been encountering "task hung" problems ever<br /> since the dummy-hcd driver was changed to use hrtimers instead of<br /> regular timers. It turns out that the problems are caused by a subtle<br /> difference between the timer_pending() and hrtimer_active() APIs.<br /> <br /> The changeover blindly replaced the first by the second. However,<br /> timer_pending() returns True when the timer is queued but not when its<br /> callback is running, whereas hrtimer_active() returns True when the<br /> hrtimer is queued _or_ its callback is running. This difference<br /> occasionally caused dummy_urb_enqueue() to think that the callback<br /> routine had not yet started when in fact it was almost finished. As a<br /> result the hrtimer was not restarted, which made it impossible for the<br /> driver to dequeue later the URB that was just enqueued. This caused<br /> usb_kill_urb() to hang, and things got worse from there.<br /> <br /> Since hrtimers have no API for telling when they are queued and the<br /> callback isn&amp;#39;t running, the driver must keep track of this for itself.<br /> That&amp;#39;s what this patch does, adding a new "timer_pending" flag and<br /> setting or clearing it at the appropriate times.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: fix user address masking non-canonical speculation issue<br /> <br /> It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical<br /> accesses in kernel space. And so using just the high bit to decide<br /> whether an access is in user space or kernel space ends up with the good<br /> old "leak speculative data" if you have the right gadget using the<br /> result:<br /> <br /> CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“<br /> <br /> Now, the kernel surrounds the access with a STAC/CLAC pair, and those<br /> instructions end up serializing execution on older Zen architectures,<br /> which closes the speculation window.<br /> <br /> But that was true only up until Zen 5, which renames the AC bit [1].<br /> That improves performance of STAC/CLAC a lot, but also means that the<br /> speculation window is now open.<br /> <br /> Note that this affects not just the new address masking, but also the<br /> regular valid_user_address() check used by access_ok(), and the asm<br /> version of the sign bit check in the get_user() helpers.<br /> <br /> It does not affect put_user() or clear_user() variants, since there&amp;#39;s no<br /> speculative result to be used in a gadget for those operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: sdm845: add missing soundwire runtime stream alloc<br /> <br /> During the migration of Soundwire runtime stream allocation from<br /> the Qualcomm Soundwire controller to SoC&amp;#39;s soundcard drivers the sdm845<br /> soundcard was forgotten.<br /> <br /> At this point any playback attempt or audio daemon startup, for instance<br /> on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer<br /> NULL dereference:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual<br /> address 0000000000000020<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000<br /> [0000000000000020] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> Modules linked in: ...<br /> CPU: 5 UID: 0 PID: 1198 Comm: aplay<br /> Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18<br /> Hardware name: Thundercomm Dragonboard 845c (DT)<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]<br /> lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]<br /> sp : ffff80008a2035c0<br /> x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000<br /> x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800<br /> x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003<br /> x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000<br /> x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec<br /> x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003<br /> x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8<br /> Call trace:<br /> sdw_stream_add_slave+0x44/0x380 [soundwire_bus]<br /> wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]<br /> snd_soc_dai_hw_params+0x3c/0xa4<br /> __soc_pcm_hw_params+0x230/0x660<br /> dpcm_be_dai_hw_params+0x1d0/0x3f8<br /> dpcm_fe_dai_hw_params+0x98/0x268<br /> snd_pcm_hw_params+0x124/0x460<br /> snd_pcm_common_ioctl+0x998/0x16e8<br /> snd_pcm_ioctl+0x34/0x58<br /> __arm64_sys_ioctl+0xac/0xf8<br /> invoke_syscall+0x48/0x104<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0xe0<br /> el0t_64_sync_handler+0x120/0x12c<br /> el0t_64_sync+0x190/0x194<br /> Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> 0000000000006108 :<br /> 6108: d503233f paciasp<br /> 610c: a9b97bfd stp x29, x30, [sp, #-112]!<br /> 6110: 910003fd mov x29, sp<br /> 6114: a90153f3 stp x19, x20, [sp, #16]<br /> 6118: a9025bf5 stp x21, x22, [sp, #32]<br /> 611c: aa0103f6 mov x22, x1<br /> 6120: 2a0303f5 mov w21, w3<br /> 6124: a90363f7 stp x23, x24, [sp, #48]<br /> 6128: aa0003f8 mov x24, x0<br /> 612c: aa0203f7 mov x23, x2<br /> 6130: a9046bf9 stp x25, x26, [sp, #64]<br /> 6134: aa0403f9 mov x25, x4