Vulnerabilities

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 /> drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_init<br /> <br /> of_graph_get_remote_node() returns remote device nodepointer with<br /> refcount 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 /> drm/meson: encoder_cvbs: Fix refcount leak in meson_encoder_cvbs_init<br /> <br /> of_graph_get_remote_node() returns remote device nodepointer with<br /> refcount 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 /> 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?