Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hfi1: Fix kernel pointer leak<br /> <br /> Pointers should be printed with %p or %px rather than cast to &amp;#39;unsigned<br /> long long&amp;#39; and printed with %llx. Change %llx to %p to print the secured<br /> pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup<br /> <br /> The ixgbe driver currently generates a NULL pointer dereference with<br /> some machine (online cpus num_rx_queues = rss_i;<br /> adapter-&gt;num_tx_queues = rss_i;<br /> adapter-&gt;num_xdp_queues = ixgbe_xdp_queues(adapter);<br /> <br /> And rss_i&amp;#39;s value is from<br /> f = &amp;adapter-&gt;ring_feature[RING_F_FDIR];<br /> rss_i = f-&gt;indices = f-&gt;limit;<br /> <br /> So "num_rx_queues" &gt; "num_xdp_queues", when run to "ixgbe_xdp_setup",<br /> for (i = 0; i num_rx_queues; i++)<br /> if (adapter-&gt;xdp_ring[i]-&gt;xsk_umem)<br /> <br /> It leads to panic.<br /> <br /> Call trace:<br /> [exception RIP: ixgbe_xdp+368]<br /> RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297<br /> RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90<br /> RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000<br /> R10: ffff9fe16202f830 R11: 0000000000000000 R12: ffff92f8f24c0000<br /> R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc<br /> 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808<br /> 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235<br /> 10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384<br /> 11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd<br /> 12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb<br /> 13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88<br /> 14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319<br /> 15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290<br /> 16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8<br /> 17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64<br /> 18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9<br /> 19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c<br /> <br /> So I fix ixgbe_max_channels so that it will not allow a setting of queues<br /> to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,<br /> take the smaller value of num_rx_queues and num_xdp_queues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: do not allow call hns3_nic_net_open repeatedly<br /> <br /> hns3_nic_net_open() is not allowed to called repeatly, but there<br /> is no checking for this. When doing device reset and setup tc<br /> concurrently, there is a small oppotunity to call hns3_nic_net_open<br /> repeatedly, and cause kernel bug by calling napi_enable twice.<br /> <br /> The calltrace information is like below:<br /> [ 3078.222780] ------------[ cut here ]------------<br /> [ 3078.230255] kernel BUG at net/core/dev.c:6991!<br /> [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O)<br /> [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1<br /> [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021<br /> [ 3078.276801] Workqueue: hclge hclge_service_task [hclge]<br /> [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)<br /> [ 3078.296168] pc : napi_enable+0x80/0x84<br /> tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3]<br /> <br /> [ 3078.314771] sp : ffff8000108abb20<br /> [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300<br /> [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000<br /> [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880<br /> [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000<br /> [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930<br /> [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4<br /> [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8<br /> [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344<br /> [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938<br /> [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0<br /> [ 3078.414657] Call trace:<br /> [ 3078.418517] napi_enable+0x80/0x84<br /> [ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3]<br /> [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3]<br /> [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge]<br /> [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge]<br /> [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge]<br /> [ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge]<br /> [ 3078.475675] process_one_work+0x1dc/0x48c<br /> [ 3078.481888] worker_thread+0x15c/0x464<br /> [ 3078.487104] kthread+0x160/0x170<br /> [ 3078.492479] ret_from_fork+0x10/0x18<br /> [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000)<br /> [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]---<br /> <br /> Once hns3_nic_net_open() is excute success, the flag<br /> HNS3_NIC_STATE_DOWN will be cleared. So add checking for this<br /> flag, directly return when HNS3_NIC_STATE_DOWN is no set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipack: ipoctal: fix stack information leak<br /> <br /> The tty driver name is used also after registering the driver and must<br /> specifically not be allocated on the stack to avoid leaking information<br /> to user space (or triggering an oops).<br /> <br /> Drivers should not try to encode topology information in the tty device<br /> name but this one snuck in through staging without anyone noticing and<br /> another driver has since copied this malpractice.<br /> <br /> Fixing the ABI is a separate issue, but this at least plugs the security<br /> hole.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: flower: protect fl_walk() with rcu<br /> <br /> Patch that refactored fl_walk() to use idr_for_each_entry_continue_ul()<br /> also removed rcu protection of individual filters which causes following<br /> use-after-free when filter is deleted concurrently. Fix fl_walk() to obtain<br /> rcu read lock while iterating and taking the filter reference and temporary<br /> release the lock while calling arg-&gt;fn() callback that can sleep.<br /> <br /> KASAN trace:<br /> <br /> [ 352.773640] ==================================================================<br /> [ 352.775041] BUG: KASAN: use-after-free in fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.776304] Read of size 4 at addr ffff8881c8251480 by task tc/2987<br /> <br /> [ 352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2<br /> [ 352.778980] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 352.781022] Call Trace:<br /> [ 352.781573] dump_stack_lvl+0x46/0x5a<br /> [ 352.782332] print_address_description.constprop.0+0x1f/0x140<br /> [ 352.783400] ? fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.784292] ? fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.785138] kasan_report.cold+0x83/0xdf<br /> [ 352.785851] ? fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.786587] kasan_check_range+0x145/0x1a0<br /> [ 352.787337] fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.788163] ? fl_put+0x10/0x10 [cls_flower]<br /> [ 352.789007] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220<br /> [ 352.790102] tcf_chain_dump+0x231/0x450<br /> [ 352.790878] ? tcf_chain_tp_delete_empty+0x170/0x170<br /> [ 352.791833] ? __might_sleep+0x2e/0xc0<br /> [ 352.792594] ? tfilter_notify+0x170/0x170<br /> [ 352.793400] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220<br /> [ 352.794477] tc_dump_tfilter+0x385/0x4b0<br /> [ 352.795262] ? tc_new_tfilter+0x1180/0x1180<br /> [ 352.796103] ? __mod_node_page_state+0x1f/0xc0<br /> [ 352.796974] ? __build_skb_around+0x10e/0x130<br /> [ 352.797826] netlink_dump+0x2c0/0x560<br /> [ 352.798563] ? netlink_getsockopt+0x430/0x430<br /> [ 352.799433] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220<br /> [ 352.800542] __netlink_dump_start+0x356/0x440<br /> [ 352.801397] rtnetlink_rcv_msg+0x3ff/0x550<br /> [ 352.802190] ? tc_new_tfilter+0x1180/0x1180<br /> [ 352.802872] ? rtnl_calcit.isra.0+0x1f0/0x1f0<br /> [ 352.803668] ? tc_new_tfilter+0x1180/0x1180<br /> [ 352.804344] ? _copy_from_iter_nocache+0x800/0x800<br /> [ 352.805202] ? kasan_set_track+0x1c/0x30<br /> [ 352.805900] netlink_rcv_skb+0xc6/0x1f0<br /> [ 352.806587] ? rht_deferred_worker+0x6b0/0x6b0<br /> [ 352.807455] ? rtnl_calcit.isra.0+0x1f0/0x1f0<br /> [ 352.808324] ? netlink_ack+0x4d0/0x4d0<br /> [ 352.809086] ? netlink_deliver_tap+0x62/0x3d0<br /> [ 352.809951] netlink_unicast+0x353/0x480<br /> [ 352.810744] ? netlink_attachskb+0x430/0x430<br /> [ 352.811586] ? __alloc_skb+0xd7/0x200<br /> [ 352.812349] netlink_sendmsg+0x396/0x680<br /> [ 352.813132] ? netlink_unicast+0x480/0x480<br /> [ 352.813952] ? __import_iovec+0x192/0x210<br /> [ 352.814759] ? netlink_unicast+0x480/0x480<br /> [ 352.815580] sock_sendmsg+0x6c/0x80<br /> [ 352.816299] ____sys_sendmsg+0x3a5/0x3c0<br /> [ 352.817096] ? kernel_sendmsg+0x30/0x30<br /> [ 352.817873] ? __ia32_sys_recvmmsg+0x150/0x150<br /> [ 352.818753] ___sys_sendmsg+0xd8/0x140<br /> [ 352.819518] ? sendmsg_copy_msghdr+0x110/0x110<br /> [ 352.820402] ? ___sys_recvmsg+0xf4/0x1a0<br /> [ 352.821110] ? __copy_msghdr_from_user+0x260/0x260<br /> [ 352.821934] ? _raw_spin_lock+0x81/0xd0<br /> [ 352.822680] ? __handle_mm_fault+0xef3/0x1b20<br /> [ 352.823549] ? rb_insert_color+0x2a/0x270<br /> [ 352.824373] ? copy_page_range+0x16b0/0x16b0<br /> [ 352.825209] ? perf_event_update_userpage+0x2d0/0x2d0<br /> [ 352.826190] ? __fget_light+0xd9/0xf0<br /> [ 352.826941] __sys_sendmsg+0xb3/0x130<br /> [ 352.827613] ? __sys_sendmsg_sock+0x20/0x20<br /> [ 352.828377] ? do_user_addr_fault+0x2c5/0x8a0<br /> [ 352.829184] ? fpregs_assert_state_consistent+0x52/0x60<br /> [ 352.830001] ? exit_to_user_mode_prepare+0x32/0x160<br /> [ 352.830845] do_syscall_64+0x35/0x80<br /> [ 352.831445] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 352.832331] RIP: 0033:0x7f7bee973c17<br /> [ <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipack: ipoctal: fix module reference leak<br /> <br /> A reference to the carrier module was taken on every open but was only<br /> released once when the final reference to the tty struct was dropped.<br /> <br /> Fix this by taking the module reference and initialising the tty driver<br /> data when installing the tty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: betop: fix slab-out-of-bounds Write in betop_probe<br /> <br /> Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver.<br /> The problem is the driver assumes the device must have an input report but<br /> some malicious devices violate this assumption.<br /> <br /> So this patch checks hid_device&amp;#39;s input is non empty before it&amp;#39;s been used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field<br /> <br /> If driver read val value sufficient for<br /> (val &amp; 0x08) &amp;&amp; (!(val &amp; 0x80)) &amp;&amp; ((val &amp; 0x7) == ((val &gt;&gt; 4) &amp; 0x7))<br /> from device then Null pointer dereference occurs.<br /> (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)<br /> Also lm75[] does not serve a purpose anymore after switching to<br /> devm_i2c_new_dummy_device() in w83791d_detect_subclients().<br /> <br /> The patch fixes possible NULL pointer dereference by removing lm75[].<br /> <br /> Found by Linux Driver Verification project (linuxtesting.org).<br /> <br /> [groeck: Dropped unnecessary continuation lines, fixed multipline alignment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field<br /> <br /> If driver read val value sufficient for<br /> (val &amp; 0x08) &amp;&amp; (!(val &amp; 0x80)) &amp;&amp; ((val &amp; 0x7) == ((val &gt;&gt; 4) &amp; 0x7))<br /> from device then Null pointer dereference occurs.<br /> (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)<br /> Also lm75[] does not serve a purpose anymore after switching to<br /> devm_i2c_new_dummy_device() in w83791d_detect_subclients().<br /> <br /> The patch fixes possible NULL pointer dereference by removing lm75[].<br /> <br /> Found by Linux Driver Verification project (linuxtesting.org).<br /> <br /> [groeck: Dropped unnecessary continuation lines, fixed multi-line alignment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: schedutil: Use kobject release() method to free sugov_tunables<br /> <br /> The struct sugov_tunables is protected by the kobject, so we can&amp;#39;t free<br /> it directly. Otherwise we would get a call trace like this:<br /> ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30<br /> WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100<br /> Modules linked in:<br /> CPU: 3 PID: 720 Comm: a.sh Tainted: G W 5.14.0-rc1-next-20210715-yocto-standard+ #507<br /> Hardware name: Marvell OcteonTX CN96XX board (DT)<br /> pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)<br /> pc : debug_print_object+0xb8/0x100<br /> lr : debug_print_object+0xb8/0x100<br /> sp : ffff80001ecaf910<br /> x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80<br /> x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000<br /> x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20<br /> x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010<br /> x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365<br /> x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69<br /> x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0<br /> x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001<br /> x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000<br /> x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000<br /> Call trace:<br /> debug_print_object+0xb8/0x100<br /> __debug_check_no_obj_freed+0x1c0/0x230<br /> debug_check_no_obj_freed+0x20/0x88<br /> slab_free_freelist_hook+0x154/0x1c8<br /> kfree+0x114/0x5d0<br /> sugov_exit+0xbc/0xc0<br /> cpufreq_exit_governor+0x44/0x90<br /> cpufreq_set_policy+0x268/0x4a8<br /> store_scaling_governor+0xe0/0x128<br /> store+0xc0/0xf0<br /> sysfs_kf_write+0x54/0x80<br /> kernfs_fop_write_iter+0x128/0x1c0<br /> new_sync_write+0xf0/0x190<br /> vfs_write+0x2d4/0x478<br /> ksys_write+0x74/0x100<br /> __arm64_sys_write+0x24/0x30<br /> invoke_syscall.constprop.0+0x54/0xe0<br /> do_el0_svc+0x64/0x158<br /> el0_svc+0x2c/0xb0<br /> el0t_64_sync_handler+0xb0/0xb8<br /> el0t_64_sync+0x198/0x19c<br /> irq event stamp: 5518<br /> hardirqs last enabled at (5517): [] console_unlock+0x554/0x6c8<br /> hardirqs last disabled at (5518): [] el1_dbg+0x28/0xa0<br /> softirqs last enabled at (5504): [] __do_softirq+0x4d0/0x6c0<br /> softirqs last disabled at (5483): [] irq_exit+0x1b0/0x1b8<br /> <br /> So split the original sugov_tunables_free() into two functions,<br /> sugov_clear_global_tunables() is just used to clear the global_tunables<br /> and the new sugov_tunables_free() is used as kobj_type::release to<br /> release the sugov_tunables safely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix use-after-free in CCMP/GCMP RX<br /> <br /> When PN checking is done in mac80211, for fragmentation we need<br /> to copy the PN to the RX struct so we can later use it to do a<br /> comparison, since commit bf30ca922a0c ("mac80211: check defrag<br /> PN against current frame").<br /> <br /> Unfortunately, in that commit I used the &amp;#39;hdr&amp;#39; variable without<br /> it being necessarily valid, so use-after-free could occur if it<br /> was necessary to reallocate (parts of) the frame.<br /> <br /> Fix this by reloading the variable after the code that results<br /> in the reallocations, if any.<br /> <br /> This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: fix missing sev_decommission in sev_receive_start<br /> <br /> DECOMMISSION the current SEV context if binding an ASID fails after<br /> RECEIVE_START. Per AMD&amp;#39;s SEV API, RECEIVE_START generates a new guest<br /> context and thus needs to be paired with DECOMMISSION:<br /> <br /> The RECEIVE_START command is the only command other than the LAUNCH_START<br /> command that generates a new guest context and guest handle.<br /> <br /> The missing DECOMMISSION can result in subsequent SEV launch failures,<br /> as the firmware leaks memory and might not able to allocate more SEV<br /> guest contexts in the future.<br /> <br /> Note, LAUNCH_START suffered the same bug, but was previously fixed by<br /> commit 934002cd660b ("KVM: SVM: Call SEV Guest Decommission if ASID<br /> binding fails").