Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: dts: qcom: replace gcc PXO with pxo_board fixed clock<br /> <br /> Replace gcc PXO phandle to pxo_board fixed clock declared in the dts.<br /> gcc driver doesn&amp;#39;t provide PXO_SRC as it&amp;#39;s a fixed-clock. This cause a<br /> kernel panic if any driver actually try to use it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register<br /> <br /> Every iteration of for_each_available_child_of_node() decrements<br /> the reference count of the previous node.<br /> When breaking early from a for_each_available_child_of_node() loop,<br /> we need to explicitly call of_node_put() on the child node.<br /> Add missing of_node_put() to avoid refcount 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 /> 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 /> 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 /> 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: 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 /> 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 /> ath11k: fix netdev open race<br /> <br /> Make sure to allocate resources needed before registering the device.<br /> <br /> This specifically avoids having a racing open() trigger a BUG_ON() in<br /> mod_timer() when ath11k_mac_op_start() is called before the<br /> mon_reap_timer as been set up.<br /> <br /> I did not see this issue with next-20220310, but I hit it on every probe<br /> with next-20220511. Perhaps some timing changed in between.<br /> <br /> Here&amp;#39;s the backtrace:<br /> <br /> [ 51.346947] kernel BUG at kernel/time/timer.c:990!<br /> [ 51.346958] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> ...<br /> [ 51.578225] Call trace:<br /> [ 51.583293] __mod_timer+0x298/0x390<br /> [ 51.589518] mod_timer+0x14/0x20<br /> [ 51.595368] ath11k_mac_op_start+0x41c/0x4a0 [ath11k]<br /> [ 51.603165] drv_start+0x38/0x60 [mac80211]<br /> [ 51.610110] ieee80211_do_open+0x29c/0x7d0 [mac80211]<br /> [ 51.617945] ieee80211_open+0x60/0xb0 [mac80211]<br /> [ 51.625311] __dev_open+0x100/0x1c0<br /> [ 51.631420] __dev_change_flags+0x194/0x210<br /> [ 51.638214] dev_change_flags+0x24/0x70<br /> [ 51.644646] do_setlink+0x228/0xdb0<br /> [ 51.650723] __rtnl_newlink+0x460/0x830<br /> [ 51.657162] rtnl_newlink+0x4c/0x80<br /> [ 51.663229] rtnetlink_rcv_msg+0x124/0x390<br /> [ 51.669917] netlink_rcv_skb+0x58/0x130<br /> [ 51.676314] rtnetlink_rcv+0x18/0x30<br /> [ 51.682460] netlink_unicast+0x250/0x310<br /> [ 51.688960] netlink_sendmsg+0x19c/0x3e0<br /> [ 51.695458] ____sys_sendmsg+0x220/0x290<br /> [ 51.701938] ___sys_sendmsg+0x7c/0xc0<br /> [ 51.708148] __sys_sendmsg+0x68/0xd0<br /> [ 51.714254] __arm64_sys_sendmsg+0x28/0x40<br /> [ 51.720900] invoke_syscall+0x48/0x120<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: fix missing skb drop on htc_tx_completion error<br /> <br /> On htc_tx_completion error the skb is not dropped. This is wrong since<br /> the completion_handler logic expect the skb to be consumed anyway even<br /> when an error is triggered. Not freeing the skb on error is a memory<br /> leak since the skb won&amp;#39;t be freed anywere else. Correctly free the<br /> packet on eid &gt;= ATH11K_HTC_EP_COUNT before returning.<br /> <br /> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers()<br /> <br /> The last case label can write two buffers &amp;#39;mc_reg_address[j]&amp;#39; and<br /> &amp;#39;mc_data[j]&amp;#39; with &amp;#39;j&amp;#39; offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE<br /> since there are no checks for this value in both case labels after the<br /> last &amp;#39;j++&amp;#39;.<br /> <br /> Instead of changing &amp;#39;&gt;&amp;#39; to &amp;#39;&gt;=&amp;#39; there, add the bounds check at the start<br /> of the second &amp;#39;case&amp;#39; (the first one already has it).<br /> <br /> Also, remove redundant last checks for &amp;#39;j&amp;#39; index bigger than array size.<br /> The expression is always false. Moreover, before or after the patch<br /> &amp;#39;table-&gt;last&amp;#39; can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it<br /> seems it can be a valid value.<br /> <br /> Detected using the static analysis tool - Svace.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.