Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Align upwards buffer size<br /> <br /> The hardware can support any image size WxH,<br /> with arbitrary W (image width) and H (image height) dimensions.<br /> <br /> Align upwards buffer size for both encoder and decoder.<br /> and leave the picture resolution unchanged.<br /> <br /> For decoder, the risk of memory out of bounds can be avoided.<br /> For both encoder and decoder, the driver will lift the limitation of<br /> resolution alignment.<br /> <br /> For example, the decoder can support jpeg whose resolution is 227x149<br /> the encoder can support nv12 1080P, won&amp;#39;t change it to 1920x1072.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath9k: fix use-after-free in ath9k_hif_usb_rx_cb<br /> <br /> Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. The<br /> problem was in incorrect htc_handle-&gt;drv_priv initialization.<br /> <br /> Probable call trace which can trigger use-after-free:<br /> <br /> ath9k_htc_probe_device()<br /> /* htc_handle-&gt;drv_priv = priv; */<br /> ath9k_htc_wait_for_target()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-gpu: fix a missing check to avoid NULL dereference<br /> <br /> &amp;#39;cache_ent&amp;#39; could be set NULL inside virtio_gpu_cmd_get_capset()<br /> and it will lead to a NULL dereference by a lately use of it<br /> (i.e., ptr = cache_ent-&gt;caps_cache). Fix it with a NULL check.<br /> <br /> <br /> [ kraxel: minor codestyle fixup ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcutorture: Fix ksoftirqd boosting timing and iteration<br /> <br /> The RCU priority boosting can fail in two situations:<br /> <br /> 1) If (nr_cpus= &gt; maxcpus=), which means if the total number of CPUs<br /> is higher than those brought online at boot, then torture_onoff() may<br /> later bring up CPUs that weren&amp;#39;t online on boot. Now since rcutorture<br /> initialization only boosts the ksoftirqds of the CPUs that have been<br /> set online on boot, the CPUs later set online by torture_onoff won&amp;#39;t<br /> benefit from the boost, making RCU priority boosting fail.<br /> <br /> 2) The ksoftirqd kthreads are boosted after the creation of<br /> rcu_torture_boost() kthreads, which opens a window large enough for these<br /> rcu_torture_boost() kthreads to wait (despite running at FIFO priority)<br /> for ksoftirqds that are still running at SCHED_NORMAL priority.<br /> <br /> The issues can trigger for example with:<br /> <br /> ./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y"<br /> <br /> [ 34.968561] rcu-torture: !!!<br /> [ 34.968627] ------------[ cut here ]------------<br /> [ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610<br /> [ 35.052043] Modules linked in:<br /> [ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1<br /> [ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014<br /> [ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610<br /> [ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82<br /> [ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202<br /> [ 37.277320] rcu: De-offloading 8<br /> [ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001<br /> [ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff<br /> [ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff<br /> [ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20<br /> [ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0<br /> [ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000<br /> [ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0<br /> [ 37.290470] Call Trace:<br /> [ 37.295049] <br /> [ 37.295065] ? preempt_count_add+0x63/0x90<br /> [ 37.295095] ? _raw_spin_lock_irqsave+0x12/0x40<br /> [ 37.295125] ? rcu_torture_stats_print+0x610/0x610<br /> [ 37.295143] rcu_torture_stats+0x29/0x70<br /> [ 37.295160] kthread+0xe3/0x110<br /> [ 37.295176] ? kthread_complete_and_exit+0x20/0x20<br /> [ 37.295193] ret_from_fork+0x22/0x30<br /> [ 37.295218] <br /> <br /> Fix this with boosting the ksoftirqds kthreads from the boosting<br /> hotplug callback itself and before the boosting kthreads are created.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: 8852a: rfk: fix div 0 exception<br /> <br /> The DPK is a kind of RF calibration whose algorithm is to fine tune<br /> parameters and calibrate, and check the result. If the result isn&amp;#39;t good<br /> enough, it could adjust parameters and try again.<br /> <br /> This issue is to read and show the result, but it could be a negative<br /> calibration result that causes divisor 0 and core dump. So, fix it by<br /> phy_div() that does division only if divisor isn&amp;#39;t zero; otherwise,<br /> zero is adopted.<br /> <br /> divide error: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1 <br /> RIP: 0010:rtw8852a_dpk+0x14ae/0x288f [rtw89_core]<br /> RSP: 0018:ffffa9bb412a7520 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 00000000000180fc RDI: ffffa141d01023c0<br /> RBP: ffffa9bb412a76a0 R08: 0000000000001319 R09: 00000000ffffff92<br /> R10: ffffffffc0292de3 R11: ffffffffc00d2f51 R12: 0000000000000000<br /> R13: ffffa141d01023c0 R14: ffffffffc0290250 R15: ffffa141d0102638<br /> FS: 00007fa99f5c2740(0000) GS:ffffa142e5e80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000013e8e010 CR3: 0000000110d2c000 CR4: 0000000000750ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> rtw89_core_sta_add+0x95/0x9c [rtw89_core ]<br /> rtw89_ops_sta_state+0x5d/0x108 [rtw89_core ]<br /> drv_sta_state+0x115/0x66f [mac80211 ]<br /> sta_info_insert_rcu+0x45c/0x713 [mac80211 ]<br /> sta_info_insert+0xf/0x1b [mac80211 ]<br /> ieee80211_prep_connection+0x9d6/0xb0c [mac80211 ]<br /> ieee80211_mgd_auth+0x2aa/0x352 [mac80211 ]<br /> cfg80211_mlme_auth+0x160/0x1f6 [cfg80211 ]<br /> nl80211_authenticate+0x2e5/0x306 [cfg80211 ]<br /> genl_rcv_msg+0x371/0x3a1<br /> ? nl80211_stop_sched_scan+0xe5/0xe5 [cfg80211 ]<br /> ? genl_rcv+0x36/0x36<br /> netlink_rcv_skb+0x8a/0xf9<br /> genl_rcv+0x28/0x36<br /> netlink_unicast+0x27b/0x3a0<br /> netlink_sendmsg+0x2aa/0x469<br /> sock_sendmsg_nosec+0x49/0x4d<br /> ____sys_sendmsg+0xe5/0x213<br /> __sys_sendmsg+0xec/0x157<br /> ? syscall_enter_from_user_mode+0xd7/0x116<br /> do_syscall_64+0x43/0x55<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> RIP: 0033:0x7fa99f6e689b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix potential 32-bit overflow when accessing ARRAY map element<br /> <br /> If BPF array map is bigger than 4GB, element pointer calculation can<br /> overflow because both index and elem_size are u32. Fix this everywhere<br /> by forcing 64-bit multiplication. Extract this formula into separate<br /> small helper and use it consistently in various places.<br /> <br /> Speculative-preventing formula utilizing index_mask trick is left as is,<br /> but explicit u64 casts are added in both places.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mcde: Fix refcount leak in mcde_dsi_bind<br /> <br /> Every iteration of for_each_available_child_of_node() decrements<br /> the reference counter of the previous node. There is no decrement<br /> when break out from the loop and results in refcount leak.<br /> Add missing of_node_put() to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kunit: executor: Fix a memory leak on failure in kunit_filter_tests<br /> <br /> It&amp;#39;s possible that memory allocation for &amp;#39;filtered&amp;#39; will fail, but for the<br /> copy of the suite to succeed. In this case, the copy could be leaked.<br /> <br /> Properly free &amp;#39;copy&amp;#39; in the error case for the allocation of &amp;#39;filtered&amp;#39;<br /> failing.<br /> <br /> Note that there may also have been a similar issue in<br /> kunit_filter_subsuites, before it was removed in "kunit: flatten<br /> kunit_suite*** to kunit_suite** in .kunit_test_suites".<br /> <br /> This was reported by clang-analyzer via the kernel test robot, here:<br /> https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/<br /> <br /> And by smatch via Dan Carpenter and the kernel test robot:<br /> https://lore.kernel.org/all/202207101328.ASjx88yj-lkp@intel.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: hisilicon/sec - don&amp;#39;t sleep when in softirq<br /> <br /> When kunpeng920 encryption driver is used to deencrypt and decrypt<br /> packets during the softirq, it is not allowed to use mutex lock. The<br /> kernel will report the following error:<br /> <br /> BUG: scheduling while atomic: swapper/57/0/0x00000300<br /> Call trace:<br /> dump_backtrace+0x0/0x1e4<br /> show_stack+0x20/0x2c<br /> dump_stack+0xd8/0x140<br /> __schedule_bug+0x68/0x80<br /> __schedule+0x728/0x840<br /> schedule+0x50/0xe0<br /> schedule_preempt_disabled+0x18/0x24<br /> __mutex_lock.constprop.0+0x594/0x5dc<br /> __mutex_lock_slowpath+0x1c/0x30<br /> mutex_lock+0x50/0x60<br /> sec_request_init+0x8c/0x1a0 [hisi_sec2]<br /> sec_process+0x28/0x1ac [hisi_sec2]<br /> sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2]<br /> sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2]<br /> crypto_skcipher_encrypt+0x2c/0x40<br /> crypto_authenc_encrypt+0xc8/0xfc [authenc]<br /> crypto_aead_encrypt+0x2c/0x40<br /> echainiv_encrypt+0x144/0x1a0 [echainiv]<br /> crypto_aead_encrypt+0x2c/0x40<br /> esp_output_tail+0x348/0x5c0 [esp4]<br /> esp_output+0x120/0x19c [esp4]<br /> xfrm_output_one+0x25c/0x4d4<br /> xfrm_output_resume+0x6c/0x1fc<br /> xfrm_output+0xac/0x3c0<br /> xfrm4_output+0x64/0x130<br /> ip_build_and_send_pkt+0x158/0x20c<br /> tcp_v4_send_synack+0xdc/0x1f0<br /> tcp_conn_request+0x7d0/0x994<br /> tcp_v4_conn_request+0x58/0x6c<br /> tcp_v6_conn_request+0xf0/0x100<br /> tcp_rcv_state_process+0x1cc/0xd60<br /> tcp_v4_do_rcv+0x10c/0x250<br /> tcp_v4_rcv+0xfc4/0x10a4<br /> ip_protocol_deliver_rcu+0xf4/0x200<br /> ip_local_deliver_finish+0x58/0x70<br /> ip_local_deliver+0x68/0x120<br /> ip_sublist_rcv_finish+0x70/0x94<br /> ip_list_rcv_finish.constprop.0+0x17c/0x1d0<br /> ip_sublist_rcv+0x40/0xb0<br /> ip_list_rcv+0x140/0x1dc<br /> __netif_receive_skb_list_core+0x154/0x28c<br /> __netif_receive_skb_list+0x120/0x1a0<br /> netif_receive_skb_list_internal+0xe4/0x1f0<br /> napi_complete_done+0x70/0x1f0<br /> gro_cell_poll+0x9c/0xb0<br /> napi_poll+0xcc/0x264<br /> net_rx_action+0xd4/0x21c<br /> __do_softirq+0x130/0x358<br /> irq_exit+0x11c/0x13c<br /> __handle_domain_irq+0x88/0xf0<br /> gic_handle_irq+0x78/0x2c0<br /> el1_irq+0xb8/0x140<br /> arch_cpu_idle+0x18/0x40<br /> default_idle_call+0x5c/0x1c0<br /> cpuidle_idle_call+0x174/0x1b0<br /> do_idle+0xc8/0x160<br /> cpu_startup_entry+0x30/0x11c<br /> secondary_start_kernel+0x158/0x1e4<br /> softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with<br /> preempt_count 00000100, exited with fffffe00?

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg<br /> <br /> Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/mdp5: Fix global state lock backoff<br /> <br /> We need to grab the lock after the early return for !hwpipe case.<br /> Otherwise, we could have hit contention yet still returned 0.<br /> <br /> Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged<br /> in CI:<br /> <br /> WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154<br /> Modules linked in:<br /> CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1<br /> Hardware name: Qualcomm Technologies, Inc. DB820c (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : drm_modeset_lock+0xf8/0x154<br /> lr : drm_atomic_get_private_obj_state+0x84/0x170<br /> sp : ffff80000cfab6a0<br /> x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00<br /> x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58<br /> x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001<br /> x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038<br /> x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0<br /> x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47<br /> x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610<br /> x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000<br /> x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029<br /> x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58<br /> Call trace:<br /> drm_modeset_lock+0xf8/0x154<br /> drm_atomic_get_private_obj_state+0x84/0x170<br /> mdp5_get_global_state+0x54/0x6c<br /> mdp5_pipe_release+0x2c/0xd4<br /> mdp5_plane_atomic_check+0x2ec/0x414<br /> drm_atomic_helper_check_planes+0xd8/0x210<br /> drm_atomic_helper_check+0x54/0xb0<br /> ...<br /> ---[ end trace 0000000000000000 ]---<br /> drm_modeset_lock attempting to lock a contended lock without backoff:<br /> drm_modeset_lock+0x148/0x154<br /> mdp5_get_global_state+0x30/0x6c<br /> mdp5_pipe_release+0x2c/0xd4<br /> mdp5_plane_atomic_check+0x290/0x414<br /> drm_atomic_helper_check_planes+0xd8/0x210<br /> drm_atomic_helper_check+0x54/0xb0<br /> drm_atomic_check_only+0x4b0/0x8f4<br /> drm_atomic_commit+0x68/0xe0<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/492701/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hinic: avoid kernel hung in hinic_get_stats64()<br /> <br /> When using hinic device as a bond slave device, and reading device stats<br /> of master bond device, the kernel may hung.<br /> <br /> The kernel panic calltrace as follows:<br /> Kernel panic - not syncing: softlockup: hung tasks<br /> Call trace:<br /> native_queued_spin_lock_slowpath+0x1ec/0x31c<br /> dev_get_stats+0x60/0xcc<br /> dev_seq_printf_stats+0x40/0x120<br /> dev_seq_show+0x1c/0x40<br /> seq_read_iter+0x3c8/0x4dc<br /> seq_read+0xe0/0x130<br /> proc_reg_read+0xa8/0xe0<br /> vfs_read+0xb0/0x1d4<br /> ksys_read+0x70/0xfc<br /> __arm64_sys_read+0x20/0x30<br /> el0_svc_common+0x88/0x234<br /> do_el0_svc+0x2c/0x90<br /> el0_svc+0x1c/0x30<br /> el0_sync_handler+0xa8/0xb0<br /> el0_sync+0x148/0x180<br /> <br /> And the calltrace of task that actually caused kernel hungs as follows:<br /> __switch_to+124<br /> __schedule+548<br /> schedule+72<br /> schedule_timeout+348<br /> __down_common+188<br /> __down+24<br /> down+104<br /> hinic_get_stats64+44 [hinic]<br /> dev_get_stats+92<br /> bond_get_stats+172 [bonding]<br /> dev_get_stats+92<br /> dev_seq_printf_stats+60<br /> dev_seq_show+24<br /> seq_read_iter+964<br /> seq_read+220<br /> proc_reg_read+164<br /> vfs_read+172<br /> ksys_read+108<br /> __arm64_sys_read+28<br /> el0_svc_common+132<br /> do_el0_svc+40<br /> el0_svc+24<br /> el0_sync_handler+164<br /> el0_sync+324<br /> <br /> When getting device stats from bond, kernel will call bond_get_stats().<br /> It first holds the spinlock bond-&gt;stats_lock, and then call<br /> hinic_get_stats64() to collect hinic device&amp;#39;s stats.<br /> However, hinic_get_stats64() calls `down(&amp;nic_dev-&gt;mgmt_lock)` to<br /> protect its critical section, which may schedule current task out.<br /> And if system is under high pressure, the task cannot be woken up<br /> immediately, which eventually triggers kernel hung panic.<br /> <br /> Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local<br /> variable in hinic_get_stats64(), there is nothing need to be protected<br /> by lock, so just removing down()/up() is ok.