Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: unmark inode in use in error path<br /> <br /> Unmark inode in use if error encountered. If the in-use flag leakage<br /> occurs in cachefiles_open_file(), Cachefiles will complain "Inode<br /> already in use" when later another cookie with the same index key is<br /> looked up.<br /> <br /> If the in-use flag leakage occurs in cachefiles_create_tmpfile(), though<br /> the "Inode already in use" warning won&amp;#39;t be triggered, fix the leakage<br /> anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix the svc_deferred_event trace class<br /> <br /> Fix a NULL deref crash that occurs when an svc_rqst is deferred<br /> while the sunrpc tracing subsystem is enabled. svc_revisit() sets<br /> dr-&gt;xprt to NULL, so it can&amp;#39;t be relied upon in the tracepoint to<br /> provide the remote&amp;#39;s address.<br /> <br /> Unfortunately we can&amp;#39;t revert the "svc_deferred_class" hunk in<br /> commit ece200ddd54b ("sunrpc: Save remote presentation address in<br /> svc_xprt for trace events") because there is now a specific check<br /> of event format specifiers for unsafe dereferences. The warning<br /> that check emits is:<br /> <br /> event svc_defer_recv has unsafe dereference of argument 1<br /> <br /> A "%pISpc" format specifier with a "struct sockaddr *" is indeed<br /> flagged by this check.<br /> <br /> Instead, take the brute-force approach used by the svcrdma_qp_error<br /> tracepoint. Convert the dr::addr field into a presentation address<br /> in the TP_fast_assign() arm of the trace event, and store that as<br /> a string. This fix can be backported to -stable kernels.<br /> <br /> In the meantime, commit c6ced22997ad ("tracing: Update print fmt<br /> check to handle new __get_sockaddr() macro") is now in v5.18, so<br /> this wonky fix can be replaced with __sockaddr() and friends<br /> properly during the v5.19 merge window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: Ensure eth header is in skb&amp;#39;s linear part<br /> <br /> After feeding a decapsulated packet to a veth device with act_mirred,<br /> skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(),<br /> which expects at least ETH_HLEN byte of linear data (as<br /> __dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes<br /> unconditionally).<br /> <br /> Use pskb_may_pull() to ensure veth_xmit() respects this constraint.<br /> <br /> kernel BUG at include/linux/skbuff.h:2328!<br /> RIP: 0010:eth_type_trans+0xcf/0x140<br /> Call Trace:<br /> <br /> __dev_forward_skb2+0xe3/0x160<br /> veth_xmit+0x6e/0x250 [veth]<br /> dev_hard_start_xmit+0xc7/0x200<br /> __dev_queue_xmit+0x47f/0x520<br /> ? skb_ensure_writable+0x85/0xa0<br /> ? skb_mpls_pop+0x98/0x1c0<br /> tcf_mirred_act+0x442/0x47e [act_mirred]<br /> tcf_action_exec+0x86/0x140<br /> fl_classify+0x1d8/0x1e0 [cls_flower]<br /> ? dma_pte_clear_level+0x129/0x1a0<br /> ? dma_pte_clear_level+0x129/0x1a0<br /> ? prb_fill_curr_block+0x2f/0xc0<br /> ? skb_copy_bits+0x11a/0x220<br /> __tcf_classify+0x58/0x110<br /> tcf_classify_ingress+0x6b/0x140<br /> __netif_receive_skb_core.constprop.0+0x47d/0xfd0<br /> ? __iommu_dma_unmap_swiotlb+0x44/0x90<br /> __netif_receive_skb_one_core+0x3d/0xa0<br /> netif_receive_skb+0x116/0x170<br /> be_process_rx+0x22f/0x330 [be2net]<br /> be_poll+0x13c/0x370 [be2net]<br /> __napi_poll+0x2a/0x170<br /> net_rx_action+0x22f/0x2f0<br /> __do_softirq+0xca/0x2a8<br /> __irq_exit_rcu+0xc1/0xe0<br /> common_interrupt+0x83/0xa0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc: Fix virt_addr_valid() for 64-bit Book3E &amp; 32-bit<br /> <br /> mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000.<br /> <br /> Because of the way __pa() works we have:<br /> __pa(0x8000000000000000) == 0, and therefore<br /> virt_to_pfn(0x8000000000000000) == 0, and therefore<br /> virt_addr_valid(0x8000000000000000) == true<br /> <br /> Which is wrong, virt_addr_valid() should be false for vmalloc space.<br /> In fact all vmalloc addresses that alias with a valid PFN will return<br /> true from virt_addr_valid(). That can cause bugs with hardened usercopy<br /> as described below by Kefeng Wang:<br /> <br /> When running ethtool eth0 on 64-bit Book3E, a BUG occurred:<br /> <br /> usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!<br /> kernel BUG at mm/usercopy.c:99<br /> ...<br /> usercopy_abort+0x64/0xa0 (unreliable)<br /> __check_heap_object+0x168/0x190<br /> __check_object_size+0x1a0/0x200<br /> dev_ethtool+0x2494/0x2b20<br /> dev_ioctl+0x5d0/0x770<br /> sock_do_ioctl+0xf0/0x1d0<br /> sock_ioctl+0x3ec/0x5a0<br /> __se_sys_ioctl+0xf0/0x160<br /> system_call_exception+0xfc/0x1f0<br /> system_call_common+0xf8/0x200<br /> <br /> The code shows below,<br /> <br /> data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));<br /> copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))<br /> <br /> The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true<br /> on 64-bit Book3E, which leads to the panic.<br /> <br /> As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va<br /> and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in<br /> the virt_addr_valid() for 64-bit, also add upper limit check to make<br /> sure the virt is below high_memory.<br /> <br /> Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start<br /> of lowmem, high_memory is the upper low virtual address, the check is<br /> suitable for 32-bit, this will fix the issue mentioned in commit<br /> 602946ec2f90 ("powerpc: Set max_mapnr correctly") too.<br /> <br /> On 32-bit there is a similar problem with high memory, that was fixed in<br /> commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that<br /> commit breaks highmem and needs to be reverted.<br /> <br /> We can&amp;#39;t easily fix __pa(), we have code that relies on its current<br /> behaviour. So for now add extra checks to virt_addr_valid().<br /> <br /> For 64-bit Book3S the extra checks are not necessary, the combination of<br /> virt_to_pfn() and pfn_valid() should yield the correct result, but they<br /> are harmless.<br /> <br /> [mpe: Add additional change log detail]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: arfs: fix use-after-free when freeing @rx_cpu_rmap<br /> <br /> The CI testing bots triggered the following splat:<br /> <br /> [ 718.203054] BUG: KASAN: use-after-free in free_irq_cpu_rmap+0x53/0x80<br /> [ 718.206349] Read of size 4 at addr ffff8881bd127e00 by task sh/20834<br /> [ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: loaded Tainted: G S W IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1<br /> [ 718.219695] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020<br /> [ 718.223418] Call Trace:<br /> [ 718.227139]<br /> [ 718.230783] dump_stack_lvl+0x33/0x42<br /> [ 718.234431] print_address_description.constprop.9+0x21/0x170<br /> [ 718.238177] ? free_irq_cpu_rmap+0x53/0x80<br /> [ 718.241885] ? free_irq_cpu_rmap+0x53/0x80<br /> [ 718.245539] kasan_report.cold.18+0x7f/0x11b<br /> [ 718.249197] ? free_irq_cpu_rmap+0x53/0x80<br /> [ 718.252852] free_irq_cpu_rmap+0x53/0x80<br /> [ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [ice]<br /> [ 718.260174] ice_remove_arfs+0x5f/0x70 [ice]<br /> [ 718.263810] ice_rebuild_arfs+0x3b/0x70 [ice]<br /> [ 718.267419] ice_rebuild+0x39c/0xb60 [ice]<br /> [ 718.270974] ? asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> [ 718.274472] ? ice_init_phy_user_cfg+0x360/0x360 [ice]<br /> [ 718.278033] ? delay_tsc+0x4a/0xb0<br /> [ 718.281513] ? preempt_count_sub+0x14/0xc0<br /> [ 718.284984] ? delay_tsc+0x8f/0xb0<br /> [ 718.288463] ice_do_reset+0x92/0xf0 [ice]<br /> [ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice]<br /> [ 718.295561] pci_reset_function+0x53/0x80<br /> <br /> [ 718.393035] Allocated by task 690:<br /> [ 718.433497] Freed by task 20834:<br /> [ 718.495688] Last potentially related work creation:<br /> [ 718.568966] The buggy address belongs to the object at ffff8881bd127e00<br /> which belongs to the cache kmalloc-96 of size 96<br /> [ 718.574085] The buggy address is located 0 bytes inside of<br /> 96-byte region [ffff8881bd127e00, ffff8881bd127e60)<br /> [ 718.579265] The buggy address belongs to the page:<br /> [ 718.598905] Memory state around the buggy address:<br /> [ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> [ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc<br /> [ 718.607794] &gt;ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> [ 718.610811] ^<br /> [ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc<br /> [ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> <br /> This is due to that free_irq_cpu_rmap() is always being called<br /> *after* (devm_)free_irq() and thus it tries to work with IRQ descs<br /> already freed. For example, on device reset the driver frees the<br /> rmap right before allocating a new one (the splat above).<br /> Make rmap creation and freeing function symmetrical with<br /> {request,free}_irq() calls i.e. do that on ifup/ifdown instead<br /> of device probe/remove/resume. These operations can be performed<br /> independently from the actual device aRFS configuration.<br /> Also, make sure ice_vsi_free_irq() clears IRQ affinity notifiers<br /> only when aRFS is disabled -- otherwise, CPU rmap sets and clears<br /> its own and they must not be touched manually.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix panic when forwarding a pkt with no in6 dev<br /> <br /> kongweibin reported a kernel panic in ip6_forward() when input interface<br /> has no in6 dev associated.<br /> <br /> The following tc commands were used to reproduce this panic:<br /> tc qdisc del dev vxlan100 root<br /> tc qdisc add dev vxlan100 root netem corrupt 5%

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().