Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Fix memory leak in msm_mdss_parse_data_bus_icc_path<br /> <br /> of_icc_get() alloc resources for path1, we should release it when not<br /> need anymore. Early return when IS_ERR_OR_NULL(path0) may leak path1.<br /> Defer getting path1 to fix this.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/514264/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: sof-nau8825: fix module alias overflow<br /> <br /> The maximum name length for a platform_device_id entry is 20 characters<br /> including the trailing NUL byte. The sof_nau8825.c file exceeds that,<br /> which causes an obscure error message:<br /> <br /> sound/soc/intel/boards/snd-soc-sof_nau8825.mod.c:35:45: error: illegal character encoding in string literal [-Werror,-Winvalid-source-encoding]<br /> MODULE_ALIAS("platform:adl_max98373_nau8825");<br /> ^~~~<br /> include/linux/module.h:168:49: note: expanded from macro &amp;#39;MODULE_ALIAS&amp;#39;<br /> ^~~~~~<br /> include/linux/module.h:165:56: note: expanded from macro &amp;#39;MODULE_INFO&amp;#39;<br /> ^~~~<br /> include/linux/moduleparam.h:26:47: note: expanded from macro &amp;#39;__MODULE_INFO&amp;#39;<br /> = __MODULE_INFO_PREFIX __stringify(tag) "=" info<br /> <br /> I could not figure out how to make the module handling robust enough<br /> to handle this better, but as a quick fix, using slightly shorter<br /> names that are still unique avoids the build issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM<br /> <br /> storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(),<br /> which in a confidential VM allocates swiotlb bounce buffers. If the I/O<br /> submission fails in storvsc_do_io(), the I/O is typically retried by higher<br /> level code, but the bounce buffer memory is never freed. The mostly like<br /> cause of I/O submission failure is a full VMBus channel ring buffer, which<br /> is not uncommon under high I/O loads. Eventually enough bounce buffer<br /> memory leaks that the confidential VM can&amp;#39;t do any I/O. The same problem<br /> can arise in a non-confidential VM with kernel boot parameter<br /> swiotlb=force.<br /> <br /> Fix this by doing scsi_dma_unmap() in the case of an I/O submission<br /> error, which frees the bounce buffer memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: da9211: Use irq handler when ready<br /> <br /> If the system does not come from reset (like when it is kexec()), the<br /> regulator might have an IRQ waiting for us.<br /> <br /> If we enable the IRQ handler before its structures are ready, we crash.<br /> <br /> This patch fixes:<br /> <br /> [ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078<br /> [ 1.316096] Call trace:<br /> [ 1.316101] blocking_notifier_call_chain+0x20/0xa8<br /> [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests<br /> [ 1.327823] regulator_notifier_call_chain+0x1c/0x2c<br /> [ 1.327825] da9211_irq_handler+0x68/0xf8<br /> [ 1.327829] irq_thread+0x11c/0x234<br /> [ 1.327833] kthread+0x13c/0x154

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/core: Fix use-after-free bug in dup_user_cpus_ptr()<br /> <br /> Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be<br /> restricted on asymmetric systems"), the setting and clearing of<br /> user_cpus_ptr are done under pi_lock for arm64 architecture. However,<br /> dup_user_cpus_ptr() accesses user_cpus_ptr without any lock<br /> protection. Since sched_setaffinity() can be invoked from another<br /> process, the process being modified may be undergoing fork() at<br /> the same time. When racing with the clearing of user_cpus_ptr in<br /> __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and<br /> possibly double-free in arm64 kernel.<br /> <br /> Commit 8f9ea86fdf99 ("sched: Always preserve the user requested<br /> cpumask") fixes this problem as user_cpus_ptr, once set, will never<br /> be cleared in a task&amp;#39;s lifetime. However, this bug was re-introduced<br /> in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in<br /> do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in<br /> do_set_cpus_allowed(). This time, it will affect all arches.<br /> <br /> Fix this bug by always clearing the user_cpus_ptr of the newly<br /> cloned/forked task before the copying process starts and check the<br /> user_cpus_ptr state of the source task under pi_lock.<br /> <br /> Note to stable, this patch won&amp;#39;t be applicable to stable releases.<br /> Just copy the new dup_user_cpus_ptr() function over.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu-v3: Don&amp;#39;t unregister on shutdown<br /> <br /> Similar to SMMUv2, this driver calls iommu_device_unregister() from the<br /> shutdown path, which removes the IOMMU groups with no coordination<br /> whatsoever with their users - shutdown methods are optional in device<br /> drivers. This can lead to NULL pointer dereferences in those drivers&amp;#39;<br /> DMA API calls, or worse.<br /> <br /> Instead of calling the full arm_smmu_device_remove() from<br /> arm_smmu_device_shutdown(), let&amp;#39;s pick only the relevant function call -<br /> arm_smmu_device_disable() - more or less the reverse of<br /> arm_smmu_device_reset() - and call just that from the shutdown path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu: Don&amp;#39;t unregister on shutdown<br /> <br /> Michael Walle says he noticed the following stack trace while performing<br /> a shutdown with "reboot -f". He suggests he got "lucky" and just hit the<br /> correct spot for the reboot while there was a packet transmission in<br /> flight.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098<br /> CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 6.1.0-rc5-00088-gf3600ff8e322 #1930<br /> Hardware name: Kontron KBox A-230-LS (DT)<br /> pc : iommu_get_dma_domain+0x14/0x20<br /> lr : iommu_dma_map_page+0x9c/0x254<br /> Call trace:<br /> iommu_get_dma_domain+0x14/0x20<br /> dma_map_page_attrs+0x1ec/0x250<br /> enetc_start_xmit+0x14c/0x10b0<br /> enetc_xmit+0x60/0xdc<br /> dev_hard_start_xmit+0xb8/0x210<br /> sch_direct_xmit+0x11c/0x420<br /> __dev_queue_xmit+0x354/0xb20<br /> ip6_finish_output2+0x280/0x5b0<br /> __ip6_finish_output+0x15c/0x270<br /> ip6_output+0x78/0x15c<br /> NF_HOOK.constprop.0+0x50/0xd0<br /> mld_sendpack+0x1bc/0x320<br /> mld_ifc_work+0x1d8/0x4dc<br /> process_one_work+0x1e8/0x460<br /> worker_thread+0x178/0x534<br /> kthread+0xe0/0xe4<br /> ret_from_fork+0x10/0x20<br /> Code: d503201f f9416800 d503233f d50323bf (f9404c00)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> <br /> This appears to be reproducible when the board has a fixed IP address,<br /> is ping flooded from another host, and "reboot -f" is used.<br /> <br /> The following is one more manifestation of the issue:<br /> <br /> $ reboot -f<br /> kvm: exiting hardware virtualization<br /> cfg80211: failed to load regulatory.db<br /> arm-smmu 5000000.iommu: disabling translation<br /> sdhci-esdhc 2140000.mmc: Removing from iommu group 11<br /> sdhci-esdhc 2150000.mmc: Removing from iommu group 12<br /> fsl-edma 22c0000.dma-controller: Removing from iommu group 17<br /> dwc3 3100000.usb: Removing from iommu group 9<br /> dwc3 3110000.usb: Removing from iommu group 10<br /> ahci-qoriq 3200000.sata: Removing from iommu group 2<br /> fsl-qdma 8380000.dma-controller: Removing from iommu group 20<br /> platform f080000.display: Removing from iommu group 0<br /> etnaviv-gpu f0c0000.gpu: Removing from iommu group 1<br /> etnaviv etnaviv: Removing from iommu group 1<br /> caam_jr 8010000.jr: Removing from iommu group 13<br /> caam_jr 8020000.jr: Removing from iommu group 14<br /> caam_jr 8030000.jr: Removing from iommu group 15<br /> caam_jr 8040000.jr: Removing from iommu group 16<br /> fsl_enetc 0000:00:00.0: Removing from iommu group 4<br /> arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications<br /> arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000<br /> fsl_enetc 0000:00:00.1: Removing from iommu group 5<br /> arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications<br /> arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000<br /> arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications<br /> arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000<br /> fsl_enetc 0000:00:00.2: Removing from iommu group 6<br /> fsl_enetc_mdio 0000:00:00.3: Removing from iommu group 8<br /> mscc_felix 0000:00:00.5: Removing from iommu group 3<br /> fsl_enetc 0000:00:00.6: Removing from iommu group 7<br /> pcieport 0001:00:00.0: Removing from iommu group 18<br /> arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications<br /> arm-smmu 5000000.iommu: GFSR 0x00000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000<br /> pcieport 0002:00:00.0: Removing from iommu group 19<br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8<br /> pc : iommu_get_dma_domain+0x14/0x20<br /> lr : iommu_dma_unmap_page+0x38/0xe0<br /> Call trace:<br /> iommu_get_dma_domain+0x14/0x20<br /> dma_unmap_page_attrs+0x38/0x1d0<br /> en<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: fix pci device refcount leak<br /> <br /> As the comment of pci_get_domain_bus_and_slot() says, it<br /> returns a PCI device with refcount incremented, when finish<br /> using it, the caller must decrement the reference count by<br /> calling pci_dev_put().<br /> <br /> In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),<br /> pci_dev_put() is called to avoid leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/mm: fix incorrect file_map_count for invalid pmd<br /> <br /> The page table check trigger BUG_ON() unexpectedly when split hugepage:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at mm/page_table_check.c:119!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> Modules linked in:<br /> CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : page_table_check_set.isra.0+0x398/0x468<br /> lr : page_table_check_set.isra.0+0x1c0/0x468<br /> [...]<br /> Call trace:<br /> page_table_check_set.isra.0+0x398/0x468<br /> __page_table_check_pte_set+0x160/0x1c0<br /> __split_huge_pmd_locked+0x900/0x1648<br /> __split_huge_pmd+0x28c/0x3b8<br /> unmap_page_range+0x428/0x858<br /> unmap_single_vma+0xf4/0x1c8<br /> zap_page_range+0x2b0/0x410<br /> madvise_vma_behavior+0xc44/0xe78<br /> do_madvise+0x280/0x698<br /> __arm64_sys_madvise+0x90/0xe8<br /> invoke_syscall.constprop.0+0xdc/0x1d8<br /> do_el0_svc+0xf4/0x3f8<br /> el0_svc+0x58/0x120<br /> el0t_64_sync_handler+0xb8/0xc0<br /> el0t_64_sync+0x19c/0x1a0<br /> [...]<br /> <br /> On arm64, pmd_leaf() will return true even if the pmd is invalid due to<br /> pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count<br /> will not only decrease once but also increase once. Then in set_pte_at(),<br /> the file_map_count increase again, and so trigger BUG_ON() unexpectedly.<br /> <br /> Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer<br /> <br /> There are 3 possible interrupt sources are handled by DP controller,<br /> HPDstatus, Controller state changes and Aux read/write transaction.<br /> At every irq, DP controller have to check isr status of every interrupt<br /> sources and service the interrupt if its isr status bits shows interrupts<br /> are pending. There is potential race condition may happen at current aux<br /> isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()<br /> even irq is not for aux read or write transaction. This may cause aux read<br /> transaction return premature if host aux data read is in the middle of<br /> waiting for sink to complete transferring data to host while irq happen.<br /> This will cause host&amp;#39;s receiving buffer contains unexpected data. This<br /> patch fixes this problem by checking aux isr and return immediately at<br /> aux isr handler if there are no any isr status bits set.<br /> <br /> Current there is a bug report regrading eDP edid corruption happen during<br /> system booting up. After lengthy debugging to found that VIDEO_READY<br /> interrupt was continuously firing during system booting up which cause<br /> dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data<br /> from aux hardware buffer which is not yet contains complete data transfer<br /> from sink. This cause edid corruption.<br /> <br /> Follows are the signature at kernel logs when problem happen,<br /> EDID has corrupt header<br /> panel-simple-dp-aux aux-aea0000.edp: Couldn&amp;#39;t identify panel via EDID<br /> <br /> Changes in v2:<br /> -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()<br /> -- add more commit text<br /> <br /> Changes in v3:<br /> -- add Stephen suggested<br /> -- dp_aux_isr() return IRQ_XXX back to caller<br /> -- dp_ctrl_isr() return IRQ_XXX back to caller<br /> <br /> Changes in v4:<br /> -- split into two patches<br /> <br /> Changes in v5:<br /> -- delete empty line between tags<br /> <br /> Changes in v6:<br /> -- remove extra "that" and fixed line more than 75 char at commit text<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/516121/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: Fix GEM handle creation UAF<br /> <br /> Userspace can guess the handle value and try to race GEM object creation<br /> with handle close, resulting in a use-after-free if we dereference the<br /> object after dropping the handle&amp;#39;s reference. For that reason, dropping<br /> the handle&amp;#39;s reference must be done *after* we are done dereferencing<br /> the object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gsmi: fix null-deref in gsmi_get_variable<br /> <br /> We can get EFI variables without fetching the attribute, so we must<br /> allow for that in gsmi.<br /> <br /> commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore<br /> access layer") added a new get_variable call with attr=NULL, which<br /> triggers panic in gsmi.