Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/secretmem: fix panic when growing a memfd_secret<br /> <br /> When one tries to grow an existing memfd_secret with ftruncate, one gets<br /> a panic [1]. For example, doing the following reliably induces the<br /> panic:<br /> <br /> fd = memfd_secret();<br /> <br /> ftruncate(fd, 10);<br /> ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);<br /> strcpy(ptr, "123456789");<br /> <br /> munmap(ptr, 10);<br /> ftruncate(fd, 20);<br /> <br /> The basic reason for this is, when we grow with ftruncate, we call down<br /> into simple_setattr, and then truncate_inode_pages_range, and eventually<br /> we try to zero part of the memory. The normal truncation code does this<br /> via the direct map (i.e., it calls page_address() and hands that to<br /> memset()).<br /> <br /> For memfd_secret though, we specifically don&amp;#39;t map our pages via the<br /> direct map (i.e. we call set_direct_map_invalid_noflush() on every<br /> fault). So the address returned by page_address() isn&amp;#39;t useful, and<br /> when we try to memset() with it we panic.<br /> <br /> This patch avoids the panic by implementing a custom setattr for<br /> memfd_secret, which detects resizes specifically (setting the size for<br /> the first time works just fine, since there are no existing pages to try<br /> to zero), and rejects them with EINVAL.<br /> <br /> One could argue growing should be supported, but I think that will<br /> require a significantly more lengthy change. So, I propose a minimal<br /> fix for the benefit of stable kernels, and then perhaps to extend<br /> memfd_secret to support growing in a separate patch.<br /> <br /> [1]:<br /> <br /> BUG: unable to handle page fault for address: ffffa0a889277028<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060<br /> Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI<br /> CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:memset_erms+0x9/0x10<br /> Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01<br /> RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8<br /> RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028<br /> RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028<br /> R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0<br /> R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8<br /> FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ? zero_user_segments+0x82/0x190<br /> truncate_inode_partial_folio+0xd4/0x2a0<br /> truncate_inode_pages_range+0x380/0x830<br /> truncate_setsize+0x63/0x80<br /> simple_setattr+0x37/0x60<br /> notify_change+0x3d8/0x4d0<br /> do_sys_ftruncate+0x162/0x1d0<br /> __x64_sys_ftruncate+0x1c/0x20<br /> do_syscall_64+0x44/0xa0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet<br /> CR2: ffffa0a889277028<br /> <br /> [lkp@intel.com: secretmem_iops can be static]<br /> [axelrasmussen@google.com: return EINVAL]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: renesas-rpc-if: fix platform-device leak in error path<br /> <br /> Make sure to free the flash platform device in the event that<br /> registration fails during probe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: aqc111: Fix out-of-bounds accesses in RX fixup<br /> <br /> aqc111_rx_fixup() contains several out-of-bounds accesses that can be<br /> triggered by a malicious (or defective) USB device, in particular:<br /> <br /> - The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds,<br /> causing OOB reads and (on big-endian systems) OOB endianness flips.<br /> - A packet can overlap the metadata array, causing a later OOB<br /> endianness flip to corrupt data used by a cloned SKB that has already<br /> been handed off into the network stack.<br /> - A packet SKB can be constructed whose tail is far beyond its end,<br /> causing out-of-bounds heap data to be considered part of the SKB&amp;#39;s<br /> data.<br /> <br /> Found doing variant analysis. Tested it with another driver (ax88179_178a), since<br /> I don&amp;#39;t have a aqc111 device to test it, but the code looks very similar.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix unexpected zeroed page mapping with zram swap<br /> <br /> Two processes under CLONE_VM cloning, user process can be corrupted by<br /> seeing zeroed page unexpectedly.<br /> <br /> CPU A CPU B<br /> <br /> do_swap_page do_swap_page<br /> SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path<br /> swap_readpage valid data<br /> swap_slot_free_notify<br /> delete zram entry<br /> swap_readpage zeroed(invalid) data<br /> pte_lock<br /> map the *zero data* to userspace<br /> pte_unlock<br /> pte_lock<br /> if (!pte_same)<br /> goto out_nomap;<br /> pte_unlock<br /> return and next refault will<br /> read zeroed data<br /> <br /> The swap_slot_free_notify is bogus for CLONE_VM case since it doesn&amp;#39;t<br /> increase the refcount of swap slot at copy_mm so it couldn&amp;#39;t catch up<br /> whether it&amp;#39;s safe or not to discard data from backing device. In the<br /> case, only the lock it could rely on to synchronize swap slot freeing is<br /> page table lock. Thus, this patch gets rid of the swap_slot_free_notify<br /> function. With this patch, CPU A will see correct data.<br /> <br /> CPU A CPU B<br /> <br /> do_swap_page do_swap_page<br /> SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path<br /> swap_readpage original data<br /> pte_lock<br /> map the original data<br /> swap_free<br /> swap_range_free<br /> bd_disk-&gt;fops-&gt;swap_slot_free_notify<br /> swap_readpage read zeroed data<br /> pte_unlock<br /> pte_lock<br /> if (!pte_same)<br /> goto out_nomap;<br /> pte_unlock<br /> return<br /> on next refault will see mapped data by CPU B<br /> <br /> The concern of the patch would increase memory consumption since it<br /> could keep wasted memory with compressed form in zram as well as<br /> uncompressed form in address space. However, most of cases of zram uses<br /> no readahead and do_swap_page is followed by swap_free so it will free<br /> the compressed form from in zram quickly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: tcmu: Fix possible page UAF<br /> <br /> tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not<br /> take refcount properly and just returns page pointer. When<br /> tcmu_try_get_data_page() returns, the returned page may have been freed by<br /> tcmu_blocks_release().<br /> <br /> We need to get_page() under cmdr_lock to avoid concurrent<br /> tcmu_blocks_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Deactivate sysctl_record_panic_msg by default in isolated guests<br /> <br /> hv_panic_page might contain guest-sensitive information, do not dump it<br /> over to Hyper-V by default in isolated guests.<br /> <br /> While at it, update some comments in hyperv_{panic,die}_event().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Check for potential null return of kmalloc_array()<br /> <br /> As the kmalloc_array() may return null, the &amp;#39;event_waiters[i].wait&amp;#39; would lead to null-pointer dereference.<br /> Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion.

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 /> block: null_blk: end timed out poll request<br /> <br /> When poll request is timed out, it is removed from the poll list,<br /> but not completed, so the request is leaked, and never get chance<br /> to complete.<br /> <br /> Fix the issue by ending it in timeout handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm integrity: fix memory corruption when tag_size is less than digest size<br /> <br /> It is possible to set up dm-integrity in such a way that the<br /> "tag_size" parameter is less than the actual digest size. In this<br /> situation, a part of the digest beyond tag_size is ignored.<br /> <br /> In this case, dm-integrity would write beyond the end of the<br /> ic-&gt;recalc_tags array and corrupt memory. The corruption happened in<br /> integrity_recalc-&gt;integrity_sector_checksum-&gt;crypto_shash_final.<br /> <br /> Fix this corruption by increasing the tags array so that it has enough<br /> padding at the end to accomodate the loop in integrity_recalc() being<br /> able to write a full digest size for the last member of the tags<br /> array.

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 /> ep93xx: clock: Fix UAF in ep93xx_clk_register_gate()<br /> <br /> arch/arm/mach-ep93xx/clock.c:154:2: warning: Use of memory after it is freed [clang-analyzer-unix.Malloc]<br /> arch/arm/mach-ep93xx/clock.c:151:2: note: Taking true branch<br /> if (IS_ERR(clk))<br /> ^<br /> arch/arm/mach-ep93xx/clock.c:152:3: note: Memory is released<br /> kfree(psc);<br /> ^~~~~~~~~~<br /> arch/arm/mach-ep93xx/clock.c:154:2: note: Use of memory after it is freed<br /> return &amp;psc-&gt;hw;<br /> ^ ~~~~~~~~