Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down<br /> <br /> There is a history of deadlock if reboot is performed at the beginning<br /> of booting. SDEV_QUIESCE was set for all LU&amp;#39;s scsi_devices by UFS<br /> shutdown, and at that time the audio driver was waiting on<br /> blk_mq_submit_bio() holding a mutex_lock while reading the fw binary.<br /> After that, a deadlock issue occurred while audio driver shutdown was<br /> waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set<br /> SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down<br /> after a UFS shutdown will return an error.<br /> <br /> [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown]<br /> [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49]<br /> [ 31.907806]I[0: swapper/0: 0] Call trace:<br /> [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338<br /> [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc<br /> [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8<br /> [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40<br /> [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac<br /> [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24<br /> [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec<br /> [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280<br /> [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c<br /> [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280<br /> [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158<br /> [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4<br /> [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0<br /> [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0<br /> [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4<br /> [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4<br /> <br /> [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter]<br /> [ 31.908783]I[0: swapper/0: 0] Call trace:<br /> [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338<br /> [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc<br /> [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8<br /> [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178<br /> [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c<br /> [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: probes: Remove broken LDR (literal) uprobe support<br /> <br /> The simulate_ldr_literal() and simulate_ldrsw_literal() functions are<br /> unsafe to use for uprobes. Both functions were originally written for<br /> use with kprobes, and access memory with plain C accesses. When uprobes<br /> was added, these were reused unmodified even though they cannot safely<br /> access user memory.<br /> <br /> There are three key problems:<br /> <br /> 1) The plain C accesses do not have corresponding extable entries, and<br /> thus if they encounter a fault the kernel will treat these as<br /> unintentional accesses to user memory, resulting in a BUG() which<br /> will kill the kernel thread, and likely lead to further issues (e.g.<br /> lockup or panic()).<br /> <br /> 2) The plain C accesses are subject to HW PAN and SW PAN, and so when<br /> either is in use, any attempt to simulate an access to user memory<br /> will fault. Thus neither simulate_ldr_literal() nor<br /> simulate_ldrsw_literal() can do anything useful when simulating a<br /> user instruction on any system with HW PAN or SW PAN.<br /> <br /> 3) The plain C accesses are privileged, as they run in kernel context,<br /> and in practice can access a small range of kernel virtual addresses.<br /> The instructions they simulate have a range of +/-1MiB, and since the<br /> simulated instructions must itself be a user instructions in the<br /> TTBR0 address range, these can address the final 1MiB of the TTBR1<br /> acddress range by wrapping downwards from an address in the first<br /> 1MiB of the TTBR0 address range.<br /> <br /> In contemporary kernels the last 8MiB of TTBR1 address range is<br /> reserved, and accesses to this will always fault, meaning this is no<br /> worse than (1).<br /> <br /> Historically, it was theoretically possible for the linear map or<br /> vmemmap to spill into the final 8MiB of the TTBR1 address range, but<br /> in practice this is extremely unlikely to occur as this would<br /> require either:<br /> <br /> * Having enough physical memory to fill the entire linear map all the<br /> way to the final 1MiB of the TTBR1 address range.<br /> <br /> * Getting unlucky with KASLR randomization of the linear map such<br /> that the populated region happens to overlap with the last 1MiB of<br /> the TTBR address range.<br /> <br /> ... and in either case if we were to spill into the final page there<br /> would be larger problems as the final page would alias with error<br /> pointers.<br /> <br /> Practically speaking, (1) and (2) are the big issues. Given there have<br /> been no reports of problems since the broken code was introduced, it<br /> appears that no-one is relying on probing these instructions with<br /> uprobes.<br /> <br /> Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW<br /> (literal), limiting the use of simulate_ldr_literal() and<br /> simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR<br /> (literal) and LDRSW (literal) will be rejected as<br /> arm_probe_decode_insn() will return INSN_REJECTED. In future we can<br /> consider introducing working uprobes support for these instructions, but<br /> this will require more significant work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices<br /> <br /> Previously, the domain_context_clear() function incorrectly called<br /> pci_for_each_dma_alias() to set up context entries for non-PCI devices.<br /> This could lead to kernel hangs or other unexpected behavior.<br /> <br /> Add a check to only call pci_for_each_dma_alias() for PCI devices. For<br /> non-PCI devices, domain_context_clear_one() is called directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()<br /> <br /> A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could<br /> possibly return NULL pointer. NULL Pointer Dereference may be<br /> triggerred without addtional check.<br /> Add a NULL check for the returned pointer.

A potential vulnerability was discovered in certain Poly video conferencing devices. The firmware flaw does not properly sanitize user input. The exploitation of this vulnerability is dependent on a layered attack and cannot be exploited by itself.

An XML External Entity (XXE) vulnerability in HAPI FHIR before v6.4.0 allows attackers to access sensitive information or execute arbitrary code via supplying a crafted request containing malicious XML entities.