Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network<br /> <br /> When copying a `struct ifaddrlblmsg` to the network, __ifal_reserved<br /> remained uninitialized, resulting in a 1-byte infoleak:<br /> <br /> BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841<br /> __netdev_start_xmit ./include/linux/netdevice.h:4841<br /> netdev_start_xmit ./include/linux/netdevice.h:4857<br /> xmit_one net/core/dev.c:3590<br /> dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606<br /> __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256<br /> dev_queue_xmit ./include/linux/netdevice.h:3009<br /> __netlink_deliver_tap_skb net/netlink/af_netlink.c:307<br /> __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325<br /> netlink_deliver_tap net/netlink/af_netlink.c:338<br /> __netlink_sendskb net/netlink/af_netlink.c:1263<br /> netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272<br /> netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360<br /> nlmsg_unicast ./include/net/netlink.h:1061<br /> rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758<br /> ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628<br /> rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082<br /> ...<br /> Uninit was created at:<br /> slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742<br /> slab_alloc_node mm/slub.c:3398<br /> __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437<br /> __do_kmalloc_node mm/slab_common.c:954<br /> __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975<br /> kmalloc_reserve net/core/skbuff.c:437<br /> __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509<br /> alloc_skb ./include/linux/skbuff.h:1267<br /> nlmsg_new ./include/net/netlink.h:964<br /> ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608<br /> rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082<br /> netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540<br /> rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319<br /> netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921<br /> ...<br /> <br /> This patch ensures that the reserved field is always initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: ralink: mt7621-pci: add sentinel to quirks table<br /> <br /> With mt7621 soc_dev_attr fixed to register the soc as a device,<br /> kernel will experience an oops in soc_device_match_attr<br /> <br /> This quirk test was introduced in the staging driver in<br /> commit 9445ccb3714c ("staging: mt7621-pci-phy: add quirks for &amp;#39;E2&amp;#39;<br /> revision using &amp;#39;soc_device_attribute&amp;#39;"). The staging driver was removed,<br /> and later re-added in commit d87da32372a0 ("phy: ralink: Add PHY driver<br /> for MT7621 PCIe PHY") for kernel 5.11

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> capabilities: fix undefined behavior in bit shift for CAP_TO_MASK<br /> <br /> Shifting signed 32-bit value by 31 bits is undefined, so changing<br /> significant bit to unsigned. The UBSAN warning calltrace like below:<br /> <br /> UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2<br /> left shift of 1 by 31 places cannot be represented in type &amp;#39;int&amp;#39;<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7d/0xa5<br /> dump_stack+0x15/0x1b<br /> ubsan_epilogue+0xe/0x4e<br /> __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c<br /> cap_task_prctl+0x561/0x6f0<br /> security_task_prctl+0x5a/0xb0<br /> __x64_sys_prctl+0x61/0x8f0<br /> do_syscall_64+0x58/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix possible crash in bnxt_hwrm_set_coal()<br /> <br /> During the error recovery sequence, the rtnl_lock is not held for the<br /> entire duration and some datastructures may be freed during the sequence.<br /> Check for the BNXT_STATE_OPEN flag instead of netif_running() to ensure<br /> that the device is fully operational before proceeding to reconfigure<br /> the coalescing settings.<br /> <br /> This will fix a possible crash like this:<br /> <br /> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G IOE --------- - - 4.18.0-348.el8.x86_64 #1<br /> Hardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019<br /> RIP: 0010:bnxt_hwrm_set_coal+0x1fb/0x2a0 [bnxt_en]<br /> Code: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6<br /> RSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5<br /> RDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28<br /> RBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c<br /> R13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0<br /> FS: 00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> ethnl_set_coalesce+0x3ce/0x4c0<br /> genl_family_rcv_msg_doit.isra.15+0x10f/0x150<br /> genl_family_rcv_msg+0xb3/0x160<br /> ? coalesce_fill_reply+0x480/0x480<br /> genl_rcv_msg+0x47/0x90<br /> ? genl_family_rcv_msg+0x160/0x160<br /> netlink_rcv_skb+0x4c/0x120<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x196/0x230<br /> netlink_sendmsg+0x204/0x3d0<br /> sock_sendmsg+0x4c/0x50<br /> __sys_sendto+0xee/0x160<br /> ? syscall_trace_enter+0x1d3/0x2c0<br /> ? __audit_syscall_exit+0x249/0x2a0<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x5b/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> RIP: 0033:0x7f38524163bb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: iosm: fix memory leak in ipc_wwan_dellink<br /> <br /> IOSM driver registers network device without setting the<br /> needs_free_netdev flag, and does NOT call free_netdev() when<br /> unregisters network device, which causes a memory leak.<br /> <br /> This patch sets needs_free_netdev to true when registers<br /> network device, which makes netdev subsystem call free_netdev()<br /> automatically after unregister_netdevice().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: mhi: fix memory leak in mhi_mbim_dellink<br /> <br /> MHI driver registers network device without setting the<br /> needs_free_netdev flag, and does NOT call free_netdev() when<br /> unregisters network device, which causes a memory leak.<br /> <br /> This patch sets needs_free_netdev to true when registers<br /> network device, which makes netdev subsystem call free_netdev()<br /> automatically after unregister_netdevice().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()<br /> <br /> ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but dereferenced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: af_can: fix NULL pointer dereference in can_rx_register()<br /> <br /> It causes NULL pointer dereference when testing as following:<br /> (a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket.<br /> (b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan<br /> link device, and bind vxcan device to bond device (can also use<br /> ifenslave command to bind vxcan device to bond device).<br /> (c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket.<br /> (d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket.<br /> <br /> The bond device invokes the can-raw protocol registration interface to<br /> receive CAN packets. However, ml_priv is not allocated to the dev,<br /> dev_rcv_lists is assigned to NULL in can_rx_register(). In this case,<br /> it will occur the NULL pointer dereference issue.<br /> <br /> The following is the stack information:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP<br /> RIP: 0010:can_rx_register+0x12d/0x1e0<br /> Call Trace:<br /> <br /> raw_enable_filters+0x8d/0x120<br /> raw_enable_allfilters+0x3b/0x130<br /> raw_bind+0x118/0x4f0<br /> __sys_bind+0x163/0x1a0<br /> __x64_sys_bind+0x1e/0x30<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix the msg-&gt;req tlv len check in tipc_nl_compat_name_table_dump_header<br /> <br /> This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value<br /> in tipc_nl_compat_name_table_dump") where it should have type casted<br /> sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative<br /> value.<br /> <br /> syzbot reported a call trace because of it:<br /> <br /> BUG: KMSAN: uninit-value in ...<br /> tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934<br /> __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238<br /> tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321<br /> tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]<br /> genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792<br /> netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501<br /> genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: Fix SQE threshold checking<br /> <br /> Current way of checking available SQE count which is based on<br /> HW updated SQB count could result in driver submitting an SQE<br /> even before CQE for the previously transmitted SQE at the same<br /> index is processed in NAPI resulting losing SKB pointers,<br /> hence a leak. Fix this by checking a consumer index which<br /> is updated once CQE is processed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lapbether: fix issue of invalid opcode in lapbeth_open()<br /> <br /> If lapb_register() failed when lapb device goes to up for the first time,<br /> the NAPI is not disabled. As a result, the invalid opcode issue is<br /> reported when the lapb device goes to up for the second time.<br /> <br /> The stack info is as follows:<br /> [ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442!<br /> [ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> [ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0<br /> [ 1958.332310][T11356] Call Trace:<br /> [ 1958.332817][T11356] <br /> [ 1958.336135][T11356] lapbeth_open+0x18/0x90<br /> [ 1958.337446][T11356] __dev_open+0x258/0x490<br /> [ 1958.341672][T11356] __dev_change_flags+0x4d4/0x6a0<br /> [ 1958.345325][T11356] dev_change_flags+0x93/0x160<br /> [ 1958.346027][T11356] devinet_ioctl+0x1276/0x1bf0<br /> [ 1958.346738][T11356] inet_ioctl+0x1c8/0x2d0<br /> [ 1958.349638][T11356] sock_ioctl+0x5d1/0x750<br /> [ 1958.356059][T11356] __x64_sys_ioctl+0x3ec/0x1790<br /> [ 1958.365594][T11356] do_syscall_64+0x35/0x80<br /> [ 1958.366239][T11356] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 1958.377381][T11356]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove()<br /> <br /> A clk_prepare_enable() call in the probe is not balanced by a corresponding<br /> clk_disable_unprepare() in the remove function.<br /> <br /> Add the missing call.