Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nci: add flush_workqueue to prevent uaf<br /> <br /> Our detector found a concurrent use-after-free bug when detaching an<br /> NCI device. The main reason for this bug is the unexpected scheduling<br /> between the used delayed mechanism (timer and workqueue).<br /> <br /> The race can be demonstrated below:<br /> <br /> Thread-1 Thread-2<br /> | nci_dev_up()<br /> | nci_open_device()<br /> | __nci_request(nci_reset_req)<br /> | nci_send_cmd<br /> | queue_work(cmd_work)<br /> nci_unregister_device() |<br /> nci_close_device() | ...<br /> del_timer_sync(cmd_timer)[1] |<br /> ... | Worker<br /> nci_free_device() | nci_cmd_work()<br /> kfree(ndev)[3] | mod_timer(cmd_timer)[2]<br /> <br /> In short, the cleanup routine thought that the cmd_timer has already<br /> been detached by [1] but the mod_timer can re-attach the timer [2], even<br /> it is already released [3], resulting in UAF.<br /> <br /> This UAF is easy to trigger, crash trace by POC is like below<br /> <br /> [ 66.703713] ==================================================================<br /> [ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490<br /> [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33<br /> [ 66.703974]<br /> [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5<br /> [ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work<br /> [ 66.703974] Call Trace:<br /> [ 66.703974] <br /> [ 66.703974] dump_stack_lvl+0x57/0x7d<br /> [ 66.703974] print_report.cold+0x5e/0x5db<br /> [ 66.703974] ? enqueue_timer+0x448/0x490<br /> [ 66.703974] kasan_report+0xbe/0x1c0<br /> [ 66.703974] ? enqueue_timer+0x448/0x490<br /> [ 66.703974] enqueue_timer+0x448/0x490<br /> [ 66.703974] __mod_timer+0x5e6/0xb80<br /> [ 66.703974] ? mark_held_locks+0x9e/0xe0<br /> [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0<br /> [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410<br /> [ 66.703974] ? queue_work_on+0x61/0x80<br /> [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130<br /> [ 66.703974] process_one_work+0x8bb/0x1510<br /> [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410<br /> [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230<br /> [ 66.703974] ? rwlock_bug.part.0+0x90/0x90<br /> [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50<br /> [ 66.703974] worker_thread+0x575/0x1190<br /> [ 66.703974] ? process_one_work+0x1510/0x1510<br /> [ 66.703974] kthread+0x2a0/0x340<br /> [ 66.703974] ? kthread_complete_and_exit+0x20/0x20<br /> [ 66.703974] ret_from_fork+0x22/0x30<br /> [ 66.703974] <br /> [ 66.703974]<br /> [ 66.703974] Allocated by task 267:<br /> [ 66.703974] kasan_save_stack+0x1e/0x40<br /> [ 66.703974] __kasan_kmalloc+0x81/0xa0<br /> [ 66.703974] nci_allocate_device+0xd3/0x390<br /> [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0<br /> [ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd<br /> [ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0<br /> [ 66.703974] tty_ioctl+0x764/0x1310<br /> [ 66.703974] __x64_sys_ioctl+0x122/0x190<br /> [ 66.703974] do_syscall_64+0x3b/0x90<br /> [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 66.703974]<br /> [ 66.703974] Freed by task 406:<br /> [ 66.703974] kasan_save_stack+0x1e/0x40<br /> [ 66.703974] kasan_set_track+0x21/0x30<br /> [ 66.703974] kasan_set_free_info+0x20/0x30<br /> [ 66.703974] __kasan_slab_free+0x108/0x170<br /> [ 66.703974] kfree+0xb0/0x330<br /> [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0<br /> [ 66.703974] nci_uart_tty_close+0xdf/0x180<br /> [ 66.703974] tty_ldisc_kill+0x73/0x110<br /> [ 66.703974] tty_ldisc_hangup+0x281/0x5b0<br /> [ 66.703974] __tty_hangup.part.0+0x431/0x890<br /> [ 66.703974] tty_release+0x3a8/0xc80<br /> [ 66.703974] __fput+0x1f0/0x8c0<br /> [ 66.703974] task_work_run+0xc9/0x170<br /> [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0<br /> [ 66.703974] syscall_exit_to_user_mode+0x19/0x50<br /> [ 66.703974] do_syscall_64+0x48/0x90<br /> [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Fix NULL pointer dereference in smc_pnet_find_ib()<br /> <br /> dev_name() was called with dev.parent as argument but without to<br /> NULL-check it before.<br /> Solve this by checking the pointer before the call to dev_name().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link<br /> <br /> When using a fixed-link, the altr_tse_pcs driver crashes<br /> due to null-pointer dereference as no phy_device is provided to<br /> tse_pcs_fix_mac_speed function. Fix this by adding a check for<br /> phy_dev before calling the tse_pcs_fix_mac_speed() function.<br /> <br /> Also clean up the tse_pcs_fix_mac_speed function a bit. There is<br /> no need to check for splitter_base and sgmii_adapter_base<br /> because the driver will fail if these 2 variables are not<br /> derived from the device tree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: Fix KASAN slab-out-of-bounds in cachefiles_set_volume_xattr<br /> <br /> Use the actual length of volume coherency data when setting the<br /> xattr to avoid the following KASAN report.<br /> <br /> BUG: KASAN: slab-out-of-bounds in cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]<br /> Write of size 4 at addr ffff888101e02af4 by task kworker/6:0/1347<br /> <br /> CPU: 6 PID: 1347 Comm: kworker/6:0 Kdump: loaded Not tainted 5.18.0-rc1-nfs-fscache-netfs+ #13<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014<br /> Workqueue: events fscache_create_volume_work [fscache]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x45/0x5a<br /> print_report.cold+0x5e/0x5db<br /> ? __lock_text_start+0x8/0x8<br /> ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]<br /> kasan_report+0xab/0x120<br /> ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]<br /> kasan_check_range+0xf5/0x1d0<br /> memcpy+0x39/0x60<br /> cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]<br /> cachefiles_acquire_volume+0x2be/0x500 [cachefiles]<br /> ? __cachefiles_free_volume+0x90/0x90 [cachefiles]<br /> fscache_create_volume_work+0x68/0x160 [fscache]<br /> process_one_work+0x3b7/0x6a0<br /> worker_thread+0x2c4/0x650<br /> ? process_one_work+0x6a0/0x6a0<br /> kthread+0x16c/0x1a0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Allocated by task 1347:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> cachefiles_set_volume_xattr+0x76/0x350 [cachefiles]<br /> cachefiles_acquire_volume+0x2be/0x500 [cachefiles]<br /> fscache_create_volume_work+0x68/0x160 [fscache]<br /> process_one_work+0x3b7/0x6a0<br /> worker_thread+0x2c4/0x650<br /> kthread+0x16c/0x1a0<br /> ret_from_fork+0x22/0x30<br /> <br /> The buggy address belongs to the object at ffff888101e02af0<br /> which belongs to the cache kmalloc-8 of size 8<br /> The buggy address is located 4 bytes inside of<br /> 8-byte region [ffff888101e02af0, ffff888101e02af8)<br /> <br /> The buggy address belongs to the physical page:<br /> page:00000000a2292d70 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x101e02<br /> flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)<br /> raw: 0017ffffc0000200 0000000000000000 dead000000000001 ffff888100042280<br /> raw: 0000000000000000 0000000080660066 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888101e02980: fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc fc<br /> ffff888101e02a00: 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00<br /> &gt;ffff888101e02a80: fc fc fc fc 00 fc fc fc fc 00 fc fc fc fc 04 fc<br /> ^<br /> ffff888101e02b00: fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc<br /> ffff888101e02b80: fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc<br /> ==================================================================

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.