Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Flush current cpu icache before other cpus<br /> <br /> On SiFive Unmatched, I recently fell onto the following BUG when booting:<br /> <br /> [ 0.000000] ftrace: allocating 36610 entries in 144 pages<br /> [ 0.000000] Oops - illegal instruction [#1]<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5<br /> [ 0.000000] Hardware name: SiFive HiFive Unmatched A00 (DT)<br /> [ 0.000000] epc : riscv_cpuid_to_hartid_mask+0x6/0xae<br /> [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a<br /> [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10<br /> [ 0.000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000<br /> [ 0.000000] t1 : 0000000000000004 t2 : 0000000000000000 s0 : ffffffff81803e60<br /> [ 0.000000] s1 : 0000000000000000 a0 : ffffffff81a22238 a1 : ffffffff81803e10<br /> [ 0.000000] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000<br /> [ 0.000000] a5 : 0000000000000000 a6 : ffffffff8000989c a7 : 0000000052464e43<br /> [ 0.000000] s2 : ffffffff81a220c8 s3 : 0000000000000000 s4 : 0000000000000000<br /> [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001<br /> [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000<br /> [ 0.000000] s11: 0000000000000004 t3 : 0000000000000001 t4 : 0000000000000008<br /> [ 0.000000] t5 : ffffffcf04000808 t6 : ffffffe3ffddf188<br /> [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000002<br /> [ 0.000000] [] riscv_cpuid_to_hartid_mask+0x6/0xae<br /> [ 0.000000] [] sbi_remote_fence_i+0x1e/0x26<br /> [ 0.000000] [] flush_icache_all+0x12/0x1a<br /> [ 0.000000] [] patch_text_nosync+0x26/0x32<br /> [ 0.000000] [] ftrace_init_nop+0x52/0x8c<br /> [ 0.000000] [] ftrace_process_locs.isra.0+0x29c/0x360<br /> [ 0.000000] [] ftrace_init+0x80/0x130<br /> [ 0.000000] [] start_kernel+0x5c4/0x8f6<br /> [ 0.000000] ---[ end trace f67eb9af4d8d492b ]---<br /> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!<br /> [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---<br /> <br /> While ftrace is looping over a list of addresses to patch, it always failed<br /> when patching the same function: riscv_cpuid_to_hartid_mask. Looking at the<br /> backtrace, the illegal instruction is encountered in this same function.<br /> However, patch_text_nosync, after patching the instructions, calls<br /> flush_icache_range. But looking at what happens in this function:<br /> <br /> flush_icache_range -&gt; flush_icache_all<br /> -&gt; sbi_remote_fence_i<br /> -&gt; __sbi_rfence_v02<br /> -&gt; riscv_cpuid_to_hartid_mask<br /> <br /> The icache and dcache of the current cpu are never synchronized between the<br /> patching of riscv_cpuid_to_hartid_mask and calling this same function.<br /> <br /> So fix this by flushing the current cpu&amp;#39;s icache before asking for the other<br /> cpus to do the same.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iwlwifi: mvm: Fix possible NULL dereference<br /> <br /> In __iwl_mvm_remove_time_event() check that &amp;#39;te_data-&gt;vif&amp;#39; is NULL<br /> before dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: don&amp;#39;t call rq_qos_ops-&gt;done_bio if the bio isn&amp;#39;t tracked<br /> <br /> rq_qos framework is only applied on request based driver, so:<br /> <br /> 1) rq_qos_done_bio() needn&amp;#39;t to be called for bio based driver<br /> <br /> 2) rq_qos_done_bio() needn&amp;#39;t to be called for bio which isn&amp;#39;t tracked,<br /> such as bios ended from error handling code.<br /> <br /> Especially in bio_endio():<br /> <br /> 1) request queue is referred via bio-&gt;bi_bdev-&gt;bd_disk-&gt;queue, which<br /> may be gone since request queue refcount may not be held in above two<br /> cases<br /> <br /> 2) q-&gt;rq_qos may be freed in blk_cleanup_queue() when calling into<br /> __rq_qos_done_bio()<br /> <br /> Fix the potential kernel panic by not calling rq_qos_ops-&gt;done_bio if<br /> the bio isn&amp;#39;t tracked. This way is safe because both ioc_rqos_done_bio()<br /> and blkcg_iolatency_done_bio() are nop if the bio isn&amp;#39;t tracked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb<br /> <br /> We should always check if skb_header_pointer&amp;#39;s return is NULL before<br /> using it, otherwise it may cause null-ptr-deref, as syzbot reported:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline]<br /> RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196<br /> Call Trace:<br /> <br /> sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109<br /> ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422<br /> ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463<br /> NF_HOOK include/linux/netfilter.h:307 [inline]<br /> NF_HOOK include/linux/netfilter.h:301 [inline]<br /> ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472<br /> dst_input include/net/dst.h:460 [inline]<br /> ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline]<br /> NF_HOOK include/linux/netfilter.h:307 [inline]<br /> NF_HOOK include/linux/netfilter.h:301 [inline]<br /> ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297

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]