Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/meson: Fix refcount leak in meson_encoder_hdmi_init<br /> <br /> of_find_device_by_node() takes reference, we should use put_device()<br /> to release it when not need anymore.<br /> Add missing put_device() in error path to avoid refcount<br /> leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tools/power turbostat: Fix file pointer leak<br /> <br /> Currently if a fscanf fails then an early return leaks an open<br /> file pointer. Fix this by fclosing the file before the return.<br /> Detected using static analysis with cppcheck:<br /> <br /> tools/power/x86/turbostat/turbostat.c:2039:3: error: Resource leak: fp [resourceLeak]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: Fix simplification of devm_spi_register_controller<br /> <br /> This reverts commit 59ebbe40fb51 ("spi: simplify<br /> devm_spi_register_controller").<br /> <br /> If devm_add_action() fails in devm_add_action_or_reset(),<br /> devm_spi_unregister() will be called, it decreases the<br /> refcount of &amp;#39;ctlr-&gt;dev&amp;#39; to 0, then it will cause uaf in<br /> the drivers that calling spi_put_controller() in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: of: Fix refcount leak bug in of_get_regulation_constraints()<br /> <br /> We should call the of_node_put() for the reference returned by<br /> of_get_child_by_name() which has increased the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: tegra20-slink: fix UAF in tegra_slink_remove()<br /> <br /> After calling spi_unregister_master(), the refcount of master will<br /> be decrease to 0, and it will be freed in spi_controller_release(),<br /> the device data also will be freed, so it will lead a UAF when using<br /> &amp;#39;tspi&amp;#39;. To fix this, get the master before unregister and put it when<br /> finish using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: wake up all waiters after z_erofs_lzma_head ready<br /> <br /> When the user mounts the erofs second times, the decompression thread<br /> may hung. The problem happens due to a sequence of steps like the<br /> following:<br /> <br /> 1) Task A called z_erofs_load_lzma_config which obtain all of the node<br /> from the z_erofs_lzma_head.<br /> <br /> 2) At this time, task B called the z_erofs_lzma_decompress and wanted to<br /> get a node. But the z_erofs_lzma_head was empty, the Task B had to<br /> sleep.<br /> <br /> 3) Task A release nodes and push nodes into the z_erofs_lzma_head. But<br /> task B was still sleeping.<br /> <br /> One example report when the hung happens:<br /> task:kworker/u3:1 state:D stack:14384 pid: 86 ppid: 2 flags:0x00004000<br /> Workqueue: erofs_unzipd z_erofs_decompressqueue_work<br /> Call Trace:<br /> <br /> __schedule+0x281/0x760<br /> schedule+0x49/0xb0<br /> z_erofs_lzma_decompress+0x4bc/0x580<br /> ? cpu_core_flags+0x10/0x10<br /> z_erofs_decompress_pcluster+0x49b/0xba0<br /> ? __update_load_avg_se+0x2b0/0x330<br /> ? __update_load_avg_se+0x2b0/0x330<br /> ? update_load_avg+0x5f/0x690<br /> ? update_load_avg+0x5f/0x690<br /> ? set_next_entity+0xbd/0x110<br /> ? _raw_spin_unlock+0xd/0x20<br /> z_erofs_decompress_queue.isra.0+0x2e/0x50<br /> z_erofs_decompressqueue_work+0x30/0x60<br /> process_one_work+0x1d3/0x3a0<br /> worker_thread+0x45/0x3a0<br /> ? process_one_work+0x3a0/0x3a0<br /> kthread+0xe2/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br />

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 /> 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()

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 /> 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 /> 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.