Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: samsung: exynos5422-dmc: Fix refcount leak in of_get_dram_timings<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> This function doesn&amp;#39;t call of_node_put() in some error paths.<br /> To unify the structure, Add put_node label and goto it on errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: cns3xxx: Fix refcount leak in cns3xxx_init<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 /> 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.