Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix regression with native SMB symlinks<br /> <br /> Some users and customers reported that their backup/copy tools started<br /> to fail when the directory being copied contained symlink targets that<br /> the client couldn&amp;#39;t parse - even when those symlinks weren&amp;#39;t followed.<br /> <br /> Fix this by allowing lstat(2) and readlink(2) to succeed even when the<br /> client can&amp;#39;t resolve the symlink target, restoring old behavior.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: ims-pcu - check record size in ims_pcu_flash_firmware()<br /> <br /> The "len" variable comes from the firmware and we generally do<br /> trust firmware, but it&amp;#39;s always better to double check. If the "len"<br /> is too large it could result in memory corruption when we do<br /> "memcpy(fragment-&gt;data, rec-&gt;data, len);"

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: tegra: check msg length in SMBUS block read<br /> <br /> For SMBUS block read, do not continue to read if the message length<br /> passed from the device is &amp;#39;0&amp;#39; or greater than the maximum allowed bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix sample vs do_exit()<br /> <br /> Baisheng Gao reported an ARM64 crash, which Mark decoded as being a<br /> synchronous external abort -- most likely due to trying to access<br /> MMIO in bad ways.<br /> <br /> The crash further shows perf trying to do a user stack sample while in<br /> exit_mmap()&amp;#39;s tlb_finish_mmu() -- i.e. while tearing down the address<br /> space it is trying to access.<br /> <br /> It turns out that we stop perf after we tear down the userspace mm; a<br /> receipie for disaster, since perf likes to access userspace for<br /> various reasons.<br /> <br /> Flip this order by moving up where we stop perf in do_exit().<br /> <br /> Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER<br /> to abort when the current task does not have an mm (exit_mm() makes<br /> sure to set current-&gt;mm = NULL; before commencing with the actual<br /> teardown). Such that CPU wide events don&amp;#39;t trip on this same problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices<br /> <br /> Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb<br /> and 64 Kb respectively. Adjust max size definitions and return correct<br /> EEPROM length based on device. Also prevent out-of-bound read/write.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wcd9375: Fix double free of regulator supplies<br /> <br /> Driver gets regulator supplies in probe path with<br /> devm_regulator_bulk_get(), so should not call regulator_bulk_free() in<br /> error and remove paths to avoid double free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: screen_info: Relocate framebuffers behind PCI bridges<br /> <br /> Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes<br /> invalid access to I/O memory.<br /> <br /> Resources behind a PCI host bridge can be relocated by a certain offset<br /> in the kernel&amp;#39;s CPU address range used for I/O. The framebuffer memory<br /> range stored in screen_info refers to the CPU addresses as seen during<br /> boot (where the offset is 0). During boot up, firmware may assign a<br /> different memory offset to the PCI host bridge and thereby relocating<br /> the framebuffer address of the PCI graphics device as seen by the kernel.<br /> The information in screen_info must be updated as well.<br /> <br /> The helper pcibios_bus_to_resource() performs the relocation of the<br /> screen_info&amp;#39;s framebuffer resource (given in PCI bus addresses). The<br /> result matches the I/O-memory resource of the PCI graphics device (given<br /> in CPU addresses). As before, we store away the information necessary to<br /> later update the information in screen_info itself.<br /> <br /> Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated<br /> EFI framebuffers") added the code for updating screen_info. It is based<br /> on similar functionality that pre-existed in efifb. Efifb uses a pointer<br /> to the PCI resource, while the newer code does a memcpy of the region.<br /> Hence efifb sees any updates to the PCI resource and avoids the issue.<br /> <br /> v3:<br /> - Only use struct pci_bus_region for PCI bus addresses (Bjorn)<br /> - Clarify address semantics in commit messages and comments (Bjorn)<br /> v2:<br /> - Fixed tags (Takashi, Ivan)<br /> - Updated information on efifb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: ep: Update read pointer only after buffer is written<br /> <br /> Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated<br /> before the buffer is written, potentially causing race conditions where<br /> the host sees an updated read pointer before the buffer is actually<br /> written. Updating rd_offset prematurely can lead to the host accessing<br /> an uninitialized or incomplete element, resulting in data corruption.<br /> <br /> Invoke the buffer write before updating rd_offset to ensure the element<br /> is fully written before signaling its availability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Add basic validation for RAS header<br /> <br /> If RAS header read from EEPROM is corrupted, it could result in trying<br /> to allocate huge memory for reading the records. Add some validation to<br /> header fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request<br /> <br /> If the request being processed is not a v4 compound request, then<br /> examining the cstate can have undefined results.<br /> <br /> This patch adds a check that the rpc procedure being executed<br /> (rq_procinfo) is the NFSPROC4_COMPOUND procedure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: carl9170: do not ping device which has failed to load firmware<br /> <br /> Syzkaller reports [1, 2] crashes caused by an attempts to ping<br /> the device which has failed to load firmware. Since such a device<br /> doesn&amp;#39;t pass &amp;#39;ieee80211_register_hw()&amp;#39;, an internal workqueue<br /> managed by &amp;#39;ieee80211_queue_work()&amp;#39; is not yet created and an<br /> attempt to queue work on it causes null-ptr-deref.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff<br /> [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd: pmf: Use device managed allocations<br /> <br /> If setting up smart PC fails for any reason then this can lead to<br /> a double free when unloading amd-pmf. This is because dev-&gt;buf was<br /> freed but never set to NULL and is again freed in amd_pmf_remove().<br /> <br /> To avoid subtle allocation bugs in failures leading to a double free<br /> change all allocations into device managed allocations.