Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srp: Set scmnd-&gt;result only when scmnd is not NULL<br /> <br /> This change fixes the following kernel NULL pointer dereference<br /> which is reproduced by blktests srp/007 occasionally.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000170<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014<br /> Workqueue: 0x0 (kblockd)<br /> RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]<br /> Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9<br /> RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282<br /> RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000<br /> RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff<br /> RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001<br /> R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000<br /> R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> __ib_process_cq+0xb7/0x280 [ib_core]<br /> ib_poll_handler+0x2b/0x130 [ib_core]<br /> irq_poll_softirq+0x93/0x150<br /> __do_softirq+0xee/0x4b8<br /> irq_exit_rcu+0xf7/0x130<br /> sysvec_apic_timer_interrupt+0x8e/0xc0<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs<br /> <br /> In brcmstb_pm_probe(), there are two kinds of leak bugs:<br /> <br /> (1) we need to add of_node_put() when for_each__matching_node() breaks<br /> (2) we need to add iounmap() for each iomap in fail path

<br /> A hard-coded AES key vulnerability was reported in the Motorola GuideMe application, along with a lack of URI sanitation, could allow for a local attacker to read arbitrary files.<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />

Use After Free vulnerability in Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user to make improper GPU memory processing operations. If the system’s memory is carefully prepared by the user, then this in turn could give them access to already freed memory.<br /> This issue affects Valhall GPU Kernel Driver: from r41p0 through r47p0; Arm 5th Gen GPU Architecture Kernel Driver: from r41p0 through r47p0.<br /> <br />

Use After Free vulnerability in Arm Ltd Bifrost GPU Kernel Driver, Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user to make improper GPU memory processing operations. On Armv8.0 cores, there are certain combinations of the Linux Kernel and Mali GPU kernel driver configurations that would allow the GPU operations to affect the userspace memory of other processes.<br /> This issue affects Bifrost GPU Kernel Driver: from r41p0 through r47p0; Valhall GPU Kernel Driver: from r41p0 through r47p0; Arm 5th Gen GPU Architecture Kernel Driver: from r41p0 through r47p0.<br /> <br />

Use After Free vulnerability in Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user to make improper GPU memory processing operations. If the system’s memory is carefully prepared by the user, then this in turn could give them access to already freed memory.<br /> This issue affects Arm 5th Gen GPU Architecture Kernel Driver: from r41p0 through r47p0.<br /> <br />

A PendingIntent hijacking vulnerability in Motorola Device Help (Genie) application that could allow local attackers to access files or interact with non-exported software components without permission. <br /> <br />

<br /> An implicit intent export vulnerability was reported in the Motorola Phone application, that could allow unauthorized access to a non-exported content provider.