Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix nfsd4_encode_fattr4() crasher<br /> <br /> Ensure that args.acl is initialized early. It is used in an<br /> unconditional call to kfree() on the way out of<br /> nfsd4_encode_fattr4().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()<br /> <br /> If we fail to allocate propname buffer, we need to drop the reference<br /> count we just took. Because the pinctrl_dt_free_maps() includes the<br /> droping operation, here we call it directly.

An unsafe .NET object deserialization vulnerability in DELMIA Apriso Release 2019 through Release 2024 could lead to pre-authentication remote code execution.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: avoid off-by-one read from userspace<br /> <br /> We try to access count + 1 byte from userspace with memdup_user(buffer,<br /> count + 1). However, the userspace only provides buffer of count bytes and<br /> only these count bytes are verified to be okay to access. To ensure the<br /> copied buffer is NUL terminated, we use memdup_user_nul instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()<br /> <br /> vgic_v2_parse_attr() is responsible for finding the vCPU that matches<br /> the user-provided CPUID, which (of course) may not be valid. If the ID<br /> is invalid, kvm_get_vcpu_by_id() returns NULL, which isn&amp;#39;t handled<br /> gracefully.<br /> <br /> Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id()<br /> actually returns something and fail the ioctl if not.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: ohci: mask bus reset interrupts between ISR and bottom half<br /> <br /> In the FireWire OHCI interrupt handler, if a bus reset interrupt has<br /> occurred, mask bus reset interrupts until bus_reset_work has serviced and<br /> cleared the interrupt.<br /> <br /> Normally, we always leave bus reset interrupts masked. We infer the bus<br /> reset from the self-ID interrupt that happens shortly thereafter. A<br /> scenario where we unmask bus reset interrupts was introduced in 2008 in<br /> a007bb857e0b26f5d8b73c2ff90782d9c0972620: If<br /> OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we<br /> will unmask bus reset interrupts so we can log them.<br /> <br /> irq_handler logs the bus reset interrupt. However, we can&amp;#39;t clear the bus<br /> reset event flag in irq_handler, because we won&amp;#39;t service the event until<br /> later. irq_handler exits with the event flag still set. If the<br /> corresponding interrupt is still unmasked, the first bus reset will<br /> usually freeze the system due to irq_handler being called again each<br /> time it exits. This freeze can be reproduced by loading firewire_ohci<br /> with "modprobe firewire_ohci debug=-1" (to enable all debugging output).<br /> Apparently there are also some cases where bus_reset_work will get called<br /> soon enough to clear the event, and operation will continue normally.<br /> <br /> This freeze was first reported a few months after a007bb85 was committed,<br /> but until now it was never fixed. The debug level could safely be set<br /> to -1 through sysfs after the module was loaded, but this would be<br /> ineffectual in logging bus reset interrupts since they were only<br /> unmasked during initialization.<br /> <br /> irq_handler will now leave the event flag set but mask bus reset<br /> interrupts, so irq_handler won&amp;#39;t be called again and there will be no<br /> freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will<br /> unmask the interrupt after servicing the event, so future interrupts<br /> will be caught as desired.<br /> <br /> As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be<br /> enabled through sysfs in addition to during initial module loading.<br /> However, when enabled through sysfs, logging of bus reset interrupts will<br /> be effective only starting with the second bus reset, after<br /> bus_reset_work has executed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: core: delete incorrect free in pinctrl_enable()<br /> <br /> The "pctldev" struct is allocated in devm_pinctrl_register_and_init().<br /> It&amp;#39;s a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),<br /> so freeing it in pinctrl_enable() will lead to a double free.<br /> <br /> The devm_pinctrl_dev_release() function frees the pindescs and destroys<br /> the mutex as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: don&amp;#39;t free NULL coalescing rule<br /> <br /> If the parsing fails, we can dereference a NULL pointer here.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan<br /> <br /> make_uffd_wp_pte() was previously doing:<br /> <br /> pte = ptep_get(ptep);<br /> ptep_modify_prot_start(ptep);<br /> pte = pte_mkuffd_wp(pte);<br /> ptep_modify_prot_commit(ptep, pte);<br /> <br /> But if another thread accessed or dirtied the pte between the first 2<br /> calls, this could lead to loss of that information. Since<br /> ptep_modify_prot_start() gets and clears atomically, the following is the<br /> correct pattern and prevents any possible race. Any access after the<br /> first call would see an invalid pte and cause a fault:<br /> <br /> pte = ptep_modify_prot_start(ptep);<br /> pte = pte_mkuffd_wp(pte);<br /> ptep_modify_prot_commit(ptep, pte);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Reapply "drm/qxl: simplify qxl_fence_wait"<br /> <br /> This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.<br /> <br /> Stephen Rostedt reports:<br /> "I went to run my tests on my VMs and the tests hung on boot up.<br /> Unfortunately, the most I ever got out was:<br /> <br /> [ 93.607888] Testing event system initcall: OK<br /> [ 93.667730] Running tests on all trace events:<br /> [ 93.669757] Testing all events: OK<br /> [ 95.631064] ------------[ cut here ]------------<br /> Timed out after 60 seconds"<br /> <br /> and further debugging points to a possible circular locking dependency<br /> between the console_owner locking and the worker pool locking.<br /> <br /> Reverting the commit allows Steve&amp;#39;s VM to boot to completion again.<br /> <br /> [ This may obviously result in the "[TTM] Buffer eviction failed"<br /> messages again, which was the reason for that original revert. But at<br /> this point this seems preferable to a non-booting system... ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix neighbour and rtable leak in smc_ib_find_route()<br /> <br /> In smc_ib_find_route(), the neighbour found by neigh_lookup() and rtable<br /> resolved by ip_route_output_flow() are not released or put before return.<br /> It may cause the refcount leak, so fix it.