Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> <br /> In brcmstb_init_sram, it pass dn to of_address_to_resource(),<br /> of_address_to_resource() will call of_find_device_by_node() to take<br /> reference, so we should release the reference returned by<br /> of_find_matching_node().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: Fix refcount leak in axxia_boot_secondary<br /> <br /> of_find_compatible_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: exynos: Fix refcount leak in exynos_map_pmu<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> of_node_put() checks null pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xtensa: xtfpga: Fix refcount leak bug in setup<br /> <br /> In machine_setup(), of_find_compatible_node() will return a node<br /> pointer with refcount incremented. We should use of_node_put() when<br /> it is not used anymore.

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 /> can: gs_usb: gs_usb_open/close(): fix memory leak<br /> <br /> The gs_usb driver appears to suffer from a malady common to many USB<br /> CAN adapter drivers in that it performs usb_alloc_coherent() to<br /> allocate a number of USB request blocks (URBs) for RX, and then later<br /> relies on usb_kill_anchored_urbs() to free them, but this doesn&amp;#39;t<br /> actually free them. As a result, this may be leaking DMA memory that&amp;#39;s<br /> been used by the driver.<br /> <br /> This commit is an adaptation of the techniques found in the esd_usb2<br /> driver where a similar design pattern led to a memory leak. It<br /> explicitly frees the RX URBs and their DMA memory via a call to<br /> usb_free_coherent(). Since the RX URBs were allocated in the<br /> gs_can_open(), we remove them in gs_can_close() rather than in the<br /> disconnect function as was done in esd_usb2.<br /> <br /> For more information, see the 928150fad41b ("can: esd_usb2: fix memory<br /> leak").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix lockdep splat in in6_dump_addrs()<br /> <br /> As reported by syzbot, we should not use rcu_dereference()<br /> when rcu_read_lock() is not held.<br /> <br /> WARNING: suspicious RCU usage<br /> 5.19.0-rc2-syzkaller #0 Not tainted<br /> <br /> net/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by syz-executor326/3617:<br /> #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223<br /> <br /> stack backtrace:<br /> CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175<br /> inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300<br /> netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275<br /> __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380<br /> netlink_dump_start include/linux/netlink.h:245 [inline]<br /> rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046<br /> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:734<br /> ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2546<br /> __sys_sendmsg net/socket.c:2575 [inline]<br /> __do_sys_sendmsg net/socket.c:2584 [inline]<br /> __se_sys_sendmsg net/socket.c:2582 [inline]<br /> __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582<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+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tunnels: do not assume mac header is set in skb_tunnel_check_pmtu()<br /> <br /> Recently added debug in commit f9aefd6b2aa3 ("net: warn if mac header<br /> was not set") caught a bug in skb_tunnel_check_pmtu(), as shown<br /> in this syzbot report [1].<br /> <br /> In ndo_start_xmit() paths, there is really no need to use skb-&gt;mac_header,<br /> because skb-&gt;data is supposed to point at it.<br /> <br /> [1] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_mac_header_len include/linux/skbuff.h:2784 [inline]<br /> WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413<br /> Modules linked in:<br /> CPU: 1 PID: 8604 Comm: syz-executor.3 Not tainted 5.19.0-rc2-syzkaller-00443-g8720bd951b8e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:skb_mac_header_len include/linux/skbuff.h:2784 [inline]<br /> RIP: 0010:skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413<br /> Code: 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 84 b9 fe ff ff 4c 89 ff e8 7c 0f d7 f9 e9 ac fe ff ff e8 c2 13 8a f9 0b e9 28 fc ff ff e8 b6 13 8a f9 48 8b 54 24 70 48 b8 00 00 00<br /> RSP: 0018:ffffc90002e4f520 EFLAGS: 00010212<br /> RAX: 0000000000000324 RBX: ffff88804d5fd500 RCX: ffffc90005b52000<br /> RDX: 0000000000040000 RSI: ffffffff87f05e3e RDI: 0000000000000003<br /> RBP: ffffc90002e4f650 R08: 0000000000000003 R09: 000000000000ffff<br /> R10: 000000000000ffff R11: 0000000000000000 R12: 000000000000ffff<br /> R13: 0000000000000000 R14: 000000000000ffcd R15: 000000000000001f<br /> FS: 00007f3babba9700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000080 CR3: 0000000075319000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> geneve_xmit_skb drivers/net/geneve.c:927 [inline]<br /> geneve_xmit+0xcf8/0x35d0 drivers/net/geneve.c:1107<br /> __netdev_start_xmit include/linux/netdevice.h:4805 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4819 [inline]<br /> __dev_direct_xmit+0x500/0x730 net/core/dev.c:4309<br /> dev_direct_xmit include/linux/netdevice.h:3007 [inline]<br /> packet_direct_xmit+0x1b8/0x2c0 net/packet/af_packet.c:282<br /> packet_snd net/packet/af_packet.c:3073 [inline]<br /> packet_sendmsg+0x21f4/0x55d0 net/packet/af_packet.c:3104<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:734<br /> ____sys_sendmsg+0x6eb/0x810 net/socket.c:2489<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2543<br /> __sys_sendmsg net/socket.c:2572 [inline]<br /> __do_sys_sendmsg net/socket.c:2581 [inline]<br /> __se_sys_sendmsg net/socket.c:2579 [inline]<br /> __x64_sys_sendmsg+0x132/0x220 net/socket.c:2579<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+0x46/0xb0<br /> RIP: 0033:0x7f3baaa89109<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f3babba9168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f3baab9bf60 RCX: 00007f3baaa89109<br /> RDX: 0000000000000000 RSI: 0000000020000a00 RDI: 0000000000000003<br /> RBP: 00007f3baaae305d R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffe74f2543f R14: 00007f3babba9300 R15: 0000000000022000<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: move bc link creation back to tipc_node_create<br /> <br /> Shuang Li reported a NULL pointer dereference crash:<br /> <br /> [] BUG: kernel NULL pointer dereference, address: 0000000000000068<br /> [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]<br /> [] Call Trace:<br /> [] <br /> [] tipc_bcast_rcv+0xa2/0x190 [tipc]<br /> [] tipc_node_bc_rcv+0x8b/0x200 [tipc]<br /> [] tipc_rcv+0x3af/0x5b0 [tipc]<br /> [] tipc_udp_recv+0xc7/0x1e0 [tipc]<br /> <br /> It was caused by the &amp;#39;l&amp;#39; passed into tipc_bcast_rcv() is NULL. When it<br /> creates a node in tipc_node_check_dest(), after inserting the new node<br /> into hashtable in tipc_node_create(), it creates the bc link. However,<br /> there is a gap between this insert and bc link creation, a bc packet<br /> may come in and get the node from the hashtable then try to dereference<br /> its bc link, which is NULL.<br /> <br /> This patch is to fix it by moving the bc link creation before inserting<br /> into the hashtable.<br /> <br /> Note that for a preliminary node becoming "real", the bc link creation<br /> should also be called before it&amp;#39;s rehashed, as we don&amp;#39;t create it for<br /> preliminary nodes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: thinkpad_acpi: Fix a memory leak of EFCH MMIO resource<br /> <br /> Unlike release_mem_region(), a call to release_resource() does not<br /> free the resource, so it has to be freed explicitly to avoid a memory<br /> leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/memhotplug: Add add_pages override for PPC<br /> <br /> With commit ffa0b64e3be5 ("powerpc: Fix virt_addr_valid() for 64-bit Book3E &amp; 32-bit")<br /> the kernel now validate the addr against high_memory value. This results<br /> in the below BUG_ON with dax pfns.<br /> <br /> [ 635.798741][T26531] kernel BUG at mm/page_alloc.c:5521!<br /> 1:mon&gt; e<br /> cpu 0x1: Vector: 700 (Program Check) at [c000000007287630]<br /> pc: c00000000055ed48: free_pages.part.0+0x48/0x110<br /> lr: c00000000053ca70: tlb_finish_mmu+0x80/0xd0<br /> sp: c0000000072878d0<br /> msr: 800000000282b033<br /> current = 0xc00000000afabe00<br /> paca = 0xc00000037ffff300 irqmask: 0x03 irq_happened: 0x05<br /> pid = 26531, comm = 50-landscape-sy<br /> kernel BUG at :5521!<br /> Linux version 5.19.0-rc3-14659-g4ec05be7c2e1 (kvaneesh@ltc-boston8) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #625 SMP Thu Jun 23 00:35:43 CDT 2022<br /> 1:mon&gt; t<br /> [link register ] c00000000053ca70 tlb_finish_mmu+0x80/0xd0<br /> [c0000000072878d0] c00000000053ca54 tlb_finish_mmu+0x64/0xd0 (unreliable)<br /> [c000000007287900] c000000000539424 exit_mmap+0xe4/0x2a0<br /> [c0000000072879e0] c00000000019fc1c mmput+0xcc/0x210<br /> [c000000007287a20] c000000000629230 begin_new_exec+0x5e0/0xf40<br /> [c000000007287ae0] c00000000070b3cc load_elf_binary+0x3ac/0x1e00<br /> [c000000007287c10] c000000000627af0 bprm_execve+0x3b0/0xaf0<br /> [c000000007287cd0] c000000000628414 do_execveat_common.isra.0+0x1e4/0x310<br /> [c000000007287d80] c00000000062858c sys_execve+0x4c/0x60<br /> [c000000007287db0] c00000000002c1b0 system_call_exception+0x160/0x2c0<br /> [c000000007287e10] c00000000000c53c system_call_common+0xec/0x250<br /> <br /> The fix is to make sure we update high_memory on memory hotplug.<br /> This is similar to what x86 does in commit 3072e413e305 ("mm/memory_hotplug: introduce add_pages")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bonding: fix use-after-free after 802.3ad slave unbind<br /> <br /> commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"),<br /> resolve case, when there is several aggregation groups in the same bond.<br /> bond_3ad_unbind_slave will invalidate (clear) aggregator when<br /> __agg_active_ports return zero. So, ad_clear_agg can be executed even, when<br /> num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for,<br /> previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave<br /> will not update slave ports list, because lag_ports==NULL. So, here we<br /> got slave ports, pointing to freed aggregator memory.<br /> <br /> Fix with checking actual number of ports in group (as was before<br /> commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ),<br /> before ad_clear_agg().<br /> <br /> The KASAN logs are as follows:<br /> <br /> [ 767.617392] ==================================================================<br /> [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470<br /> [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767<br /> [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15<br /> [ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT)<br /> [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler<br /> [ 767.666468] Call trace:<br /> [ 767.668930] dump_backtrace+0x0/0x2d0<br /> [ 767.672625] show_stack+0x24/0x30<br /> [ 767.675965] dump_stack_lvl+0x68/0x84<br /> [ 767.679659] print_address_description.constprop.0+0x74/0x2b8<br /> [ 767.685451] kasan_report+0x1f0/0x260<br /> [ 767.689148] __asan_load2+0x94/0xd0<br /> [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470