Vulnerabilities

An Implicit intent vulnerability was reported in the Motorola framework that could allow an attacker to read telephony-related data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> peci: cpu: Fix use-after-free in adev_release()<br /> <br /> When auxiliary_device_add() returns an error, auxiliary_device_uninit()<br /> is called, which causes refcount for device to be decremented and<br /> .release callback will be triggered.<br /> <br /> Because adev_release() re-calls auxiliary_device_uninit(), it will cause<br /> use-after-free:<br /> [ 1269.455172] WARNING: CPU: 0 PID: 14267 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15<br /> [ 1269.464007] refcount_t: underflow; use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()<br /> <br /> syzbot is hitting percpu_rwsem_assert_held(&amp;cpu_hotplug_lock) warning at<br /> cpuset_attach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix<br /> threadgroup_rwsem cpus_read_lock() deadlock") missed that<br /> cpuset_attach() is also called from cgroup_attach_task_all().<br /> Add cpus_read_lock() like what cgroup_procs_write_start() does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: fdt: fix off-by-one error in unflatten_dt_nodes()<br /> <br /> Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")<br /> forgot to fix up the depth check in the loop body in unflatten_dt_nodes()<br /> which makes it possible to overflow the nps[] buffer...<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with the SVACE static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Fix possible access to freed memory in link clear<br /> <br /> After modifying the QP to the Error state, all RX WR would be completed<br /> with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not<br /> wait for it is done, but destroy the QP and free the link group directly.<br /> So there is a risk that accessing the freed memory in tasklet context.<br /> <br /> Here is a crash example:<br /> <br /> BUG: unable to handle page fault for address: ffffffff8f220860<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060<br /> Oops: 0002 [#1] SMP PTI<br /> CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23<br /> Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018<br /> RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0<br /> Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32<br /> RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086<br /> RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000<br /> RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00<br /> RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b<br /> R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010<br /> R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040<br /> FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> _raw_spin_lock_irqsave+0x30/0x40<br /> mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]<br /> smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]<br /> tasklet_action_common.isra.21+0x66/0x100<br /> __do_softirq+0xd5/0x29c<br /> asm_call_irq_on_stack+0x12/0x20<br /> <br /> do_softirq_own_stack+0x37/0x40<br /> irq_exit_rcu+0x9d/0xa0<br /> sysvec_call_function_single+0x34/0x80<br /> asm_sysvec_call_function_single+0x12/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix pcluster use-after-free on UP platforms<br /> <br /> During stress testing with CONFIG_SMP disabled, KASAN reports as below:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30<br /> Read of size 8 at addr ffff8881094223f8 by task stress/7789<br /> <br /> CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3<br /> Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011<br /> Call Trace:<br /> <br /> ..<br /> __mutex_lock+0xe5/0xc30<br /> ..<br /> z_erofs_do_read_page+0x8ce/0x1560<br /> ..<br /> z_erofs_readahead+0x31c/0x580<br /> ..<br /> Freed by task 7787<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x20/0x30<br /> kasan_set_free_info+0x20/0x40<br /> __kasan_slab_free+0x10c/0x190<br /> kmem_cache_free+0xed/0x380<br /> rcu_core+0x3d5/0xc90<br /> __do_softirq+0x12d/0x389<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_record_aux_stack+0x97/0xb0<br /> call_rcu+0x3d/0x3f0<br /> erofs_shrink_workstation+0x11f/0x210<br /> erofs_shrink_scan+0xdc/0x170<br /> shrink_slab.constprop.0+0x296/0x530<br /> drop_slab+0x1c/0x70<br /> drop_caches_sysctl_handler+0x70/0x80<br /> proc_sys_call_handler+0x20a/0x2f0<br /> vfs_write+0x555/0x6c0<br /> ksys_write+0xbe/0x160<br /> do_syscall_64+0x3b/0x90<br /> <br /> The root cause is that erofs_workgroup_unfreeze() doesn&amp;#39;t reset to<br /> orig_val thus it causes a race that the pcluster reuses unexpectedly<br /> before freeing.<br /> <br /> Since UP platforms are quite rare now, such path becomes unnecessary.<br /> Let&amp;#39;s drop such specific-designed path directly instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/core: Fix a nested dead lock as part of ODP flow<br /> <br /> Fix a nested dead lock as part of ODP flow by using mmput_async().<br /> <br /> From the below call trace [1] can see that calling mmput() once we have<br /> the umem_odp-&gt;umem_mutex locked as required by<br /> ib_umem_odp_map_dma_and_lock() might trigger in the same task the<br /> exit_mmap()-&gt;__mmu_notifier_release()-&gt;mlx5_ib_invalidate_range() which<br /> may dead lock when trying to lock the same mutex.<br /> <br /> Moving to use mmput_async() will solve the problem as the above<br /> exit_mmap() flow will be called in other task and will be executed once<br /> the lock will be available.<br /> <br /> [1]<br /> [64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid:<br /> 2 flags:0x00004000<br /> [64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]<br /> [64843.077719] Call Trace:<br /> [64843.077722] <br /> [64843.077724] __schedule+0x23d/0x590<br /> [64843.077729] schedule+0x4e/0xb0<br /> [64843.077735] schedule_preempt_disabled+0xe/0x10<br /> [64843.077740] __mutex_lock.constprop.0+0x263/0x490<br /> [64843.077747] __mutex_lock_slowpath+0x13/0x20<br /> [64843.077752] mutex_lock+0x34/0x40<br /> [64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib]<br /> [64843.077808] __mmu_notifier_release+0x1a4/0x200<br /> [64843.077816] exit_mmap+0x1bc/0x200<br /> [64843.077822] ? walk_page_range+0x9c/0x120<br /> [64843.077828] ? __cond_resched+0x1a/0x50<br /> [64843.077833] ? mutex_lock+0x13/0x40<br /> [64843.077839] ? uprobe_clear_state+0xac/0x120<br /> [64843.077860] mmput+0x5f/0x140<br /> [64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core]<br /> [64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib]<br /> [64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib]<br /> [64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560<br /> [mlx5_ib]<br /> [64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib]<br /> [64843.078051] process_one_work+0x22b/0x3d0<br /> [64843.078059] worker_thread+0x53/0x410<br /> [64843.078065] ? process_one_work+0x3d0/0x3d0<br /> [64843.078073] kthread+0x12a/0x150<br /> [64843.078079] ? set_kthread_struct+0x50/0x50<br /> [64843.078085] ret_from_fork+0x22/0x30<br /> [64843.078093]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: fix UAF when detecting digest errors<br /> <br /> We should also bail from the io_work loop when we set rd_enabled to true,<br /> so we don&amp;#39;t attempt to read data from the socket when the TCP stream is<br /> already out-of-sync or corrupted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: sr: fix out-of-bounds read when setting HMAC data.<br /> <br /> The SRv6 layer allows defining HMAC data that can later be used to sign IPv6<br /> Segment Routing Headers. This configuration is realised via netlink through<br /> four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and<br /> SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual<br /> length of the SECRET attribute, it is possible to provide invalid combinations<br /> (e.g., secret = "", secretlen = 64). This case is not checked in the code and<br /> with an appropriately crafted netlink message, an out-of-bounds read of up<br /> to 64 bytes (max secret length) can occur past the skb end pointer and into<br /> skb_shared_info:<br /> <br /> Breakpoint 1, seg6_genl_sethmac (skb=, info=) at net/ipv6/seg6.c:208<br /> 208 memcpy(hinfo-&gt;secret, secret, slen);<br /> (gdb) bt<br /> #0 seg6_genl_sethmac (skb=, info=) at net/ipv6/seg6.c:208<br /> #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600,<br /> extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 , family=,<br /> family=) at net/netlink/genetlink.c:731<br /> #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00,<br /> family=0xffffffff82fef6c0 ) at net/netlink/genetlink.c:775<br /> #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792<br /> #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 )<br /> at net/netlink/af_netlink.c:2501<br /> #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803<br /> #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000)<br /> at net/netlink/af_netlink.c:1319<br /> #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=)<br /> at net/netlink/af_netlink.c:1345<br /> #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=, msg=0xffffc90000ba7e48, len=) at net/netlink/af_netlink.c:1921<br /> ...<br /> (gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)-&gt;head + ((struct sk_buff *)0xffff88800b1f9f00)-&gt;end<br /> $1 = 0xffff88800b1b76c0<br /> (gdb) p/x secret<br /> $2 = 0xffff88800b1b76c0<br /> (gdb) p slen<br /> $3 = 64 &amp;#39;@&amp;#39;<br /> <br /> The OOB data can then be read back from userspace by dumping HMAC state. This<br /> commit fixes this by ensuring SECRETLEN cannot exceed the actual length of<br /> SECRET.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix kernel crash during module removal<br /> <br /> The driver incorrectly frees client instance and subsequent<br /> i40e module removal leads to kernel crash.<br /> <br /> Reproducer:<br /> 1. Do ethtool offline test followed immediately by another one<br /> host# ethtool -t eth0 offline; ethtool -t eth0 offline<br /> 2. Remove recursively irdma module that also removes i40e module<br /> host# modprobe -r irdma<br /> <br /> Result:<br /> [ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting<br /> [ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished<br /> [ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting<br /> [ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished<br /> [ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110<br /> [ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2<br /> [ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01<br /> [ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1<br /> [ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030<br /> [ 8687.768755] #PF: supervisor read access in kernel mode<br /> [ 8687.773895] #PF: error_code(0x0000) - not-present page<br /> [ 8687.779034] PGD 0 P4D 0<br /> [ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2<br /> [ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019<br /> [ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e]<br /> [ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b<br /> [ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202<br /> [ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000<br /> [ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000<br /> [ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000<br /> [ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0<br /> [ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008<br /> [ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000<br /> [ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0<br /> [ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 8687.905572] PKRU: 55555554<br /> [ 8687.908286] Call Trace:<br /> [ 8687.910737] <br /> [ 8687.912843] i40e_remove+0x2c0/0x330 [i40e]<br /> [ 8687.917040] pci_device_remove+0x33/0xa0<br /> [ 8687.920962] device_release_driver_internal+0x1aa/0x230<br /> [ 8687.926188] driver_detach+0x44/0x90<br /> [ 8687.929770] bus_remove_driver+0x55/0xe0<br /> [ 8687.933693] pci_unregister_driver+0x2a/0xb0<br /> [ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e]<br /> <br /> Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this<br /> failure is indicated back to i40e_client_subtask() that calls<br /> i40e_client_del_instance() to free client instance referenced<br /> by pf-&gt;cinst and sets this pointer to NULL. During the module<br /> removal i40e_remove() calls i40e_lan_del_device() that dereferences<br /> pf-&gt;cinst that is NULL -&gt; crash.<br /> Do not remove client instance when client open callbacks fails and<br /> just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs<br /> to take care about this situation (when netdev is up and client<br /> is NOT opened) in i40e_notify_client_of_netdev_close() and<br /> calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED<br /> is set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: TX zerocopy should not sense pfmemalloc status<br /> <br /> We got a recent syzbot report [1] showing a possible misuse<br /> of pfmemalloc page status in TCP zerocopy paths.<br /> <br /> Indeed, for pages coming from user space or other layers,<br /> using page_is_pfmemalloc() is moot, and possibly could give<br /> false positives.<br /> <br /> There has been attempts to make page_is_pfmemalloc() more robust,<br /> but not using it in the first place in this context is probably better,<br /> removing cpu cycles.<br /> <br /> Note to stable teams :<br /> <br /> You need to backport 84ce071e38a6 ("net: introduce<br /> __skb_fill_page_desc_noacc") as a prereq.<br /> <br /> Race is more probable after commit c07aea3ef4d4<br /> ("mm: add a signature in struct page") because page_is_pfmemalloc()<br /> is now using low order bit from page-&gt;lru.next, which can change<br /> more often than page-&gt;index.<br /> <br /> Low order bit should never be set for lru.next (when used as an anchor<br /> in LRU list), so KCSAN report is mostly a false positive.<br /> <br /> Backporting to older kernel versions seems not necessary.<br /> <br /> [1]<br /> BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag<br /> <br /> write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:<br /> __list_add include/linux/list.h:73 [inline]<br /> list_add include/linux/list.h:88 [inline]<br /> lruvec_add_folio include/linux/mm_inline.h:105 [inline]<br /> lru_add_fn+0x440/0x520 mm/swap.c:228<br /> folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246<br /> folio_batch_add_and_move mm/swap.c:263 [inline]<br /> folio_add_lru+0xf1/0x140 mm/swap.c:490<br /> filemap_add_folio+0xf8/0x150 mm/filemap.c:948<br /> __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981<br /> pagecache_get_page+0x26/0x190 mm/folio-compat.c:104<br /> grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116<br /> ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988<br /> generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738<br /> ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270<br /> ext4_file_write_iter+0x2e3/0x1210<br /> call_write_iter include/linux/fs.h:2187 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x468/0x760 fs/read_write.c:578<br /> ksys_write+0xe8/0x1a0 fs/read_write.c:631<br /> __do_sys_write fs/read_write.c:643 [inline]<br /> __se_sys_write fs/read_write.c:640 [inline]<br /> __x64_sys_write+0x3e/0x50 fs/read_write.c:640<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:<br /> page_is_pfmemalloc include/linux/mm.h:1740 [inline]<br /> __skb_fill_page_desc include/linux/skbuff.h:2422 [inline]<br /> skb_fill_page_desc include/linux/skbuff.h:2443 [inline]<br /> tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018<br /> do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075<br /> tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]<br /> tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150<br /> inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833<br /> kernel_sendpage+0x184/0x300 net/socket.c:3561<br /> sock_sendpage+0x5a/0x70 net/socket.c:1054<br /> pipe_to_sendpage+0x128/0x160 fs/splice.c:361<br /> splice_from_pipe_feed fs/splice.c:415 [inline]<br /> __splice_from_pipe+0x222/0x4d0 fs/splice.c:559<br /> splice_from_pipe fs/splice.c:594 [inline]<br /> generic_splice_sendpage+0x89/0xc0 fs/splice.c:743<br /> do_splice_from fs/splice.c:764 [inline]<br /> direct_splice_actor+0x80/0xa0 fs/splice.c:931<br /> splice_direct_to_actor+0x305/0x620 fs/splice.c:886<br /> do_splice_direct+0xfb/0x180 fs/splice.c:974<br /> do_sendfile+0x3bf/0x910 fs/read_write.c:1249<br /> __do_sys_sendfile64 fs/read_write.c:1317 [inline]<br /> __se_sys_sendfile64 fs/read_write.c:1303 [inline]<br /> __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x0000000000000000 -&gt; 0xffffea0004a1d288<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: clean up hook list when offload flags check fails<br /> <br /> splice back the hook list so nft_chain_release_hook() has a chance to<br /> release the hooks.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810180b100 (size 96):<br /> comm "syz-executor133", pid 3619, jiffies 4294945714 (age 12.690s)<br /> hex dump (first 32 bytes):<br /> 28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff (d#.....(d#.....<br /> 90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................<br /> backtrace:<br /> [] kmalloc include/linux/slab.h:600 [inline]<br /> [] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901<br /> [] nft_chain_parse_netdev net/netfilter/nf_tables_api.c:1998 [inline]<br /> [] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073<br /> [] nf_tables_addchain.constprop.0+0x10b/0x950 net/netfilter/nf_tables_api.c:2218<br /> [] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593<br /> [] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517<br /> [] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:638 [inline]<br /> [] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656<br /> [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345<br /> [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921<br /> [] sock_sendmsg_nosec net/socket.c:714 [inline]<br /> [] sock_sendmsg+0x56/0x80 net/socket.c:734<br /> [] ____sys_sendmsg+0x36c/0x390 net/socket.c:2482<br /> [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536<br /> [] __sys_sendmsg+0x88/0x100 net/socket.c:2565<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd