Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: fix memleak in security_read_state_kernel()<br /> <br /> In this function, it directly returns the result of __security_read_policy<br /> without freeing the allocated memory in *data, cause memory leak issue,<br /> so free the memory if __security_read_policy failed.<br /> <br /> [PM: subject line tweak]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: hibernate: defer device probing when resuming from hibernation<br /> <br /> syzbot is reporting hung task at misc_open() [1], for there is a race<br /> window of AB-BA deadlock which involves probe_count variable. Currently<br /> wait_for_device_probe() from snapshot_open() from misc_open() can sleep<br /> forever with misc_mtx held if probe_count cannot become 0.<br /> <br /> When a device is probed by hub_event() work function, probe_count is<br /> incremented before the probe function starts, and probe_count is<br /> decremented after the probe function completed.<br /> <br /> There are three cases that can prevent probe_count from dropping to 0.<br /> <br /> (a) A device being probed stopped responding (i.e. broken/malicious<br /> hardware).<br /> <br /> (b) A process emulating a USB device using /dev/raw-gadget interface<br /> stopped responding for some reason.<br /> <br /> (c) New device probe requests keeps coming in before existing device<br /> probe requests complete.<br /> <br /> The phenomenon syzbot is reporting is (b). A process which is holding<br /> system_transition_mutex and misc_mtx is waiting for probe_count to become<br /> 0 inside wait_for_device_probe(), but the probe function which is called<br /> from hub_event() work function is waiting for the processes which are<br /> blocked at mutex_lock(&amp;misc_mtx) to respond via /dev/raw-gadget interface.<br /> <br /> This patch mitigates (b) by deferring wait_for_device_probe() from<br /> snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that<br /> the possibility of (b) remains as long as any thread which is emulating a<br /> USB device via /dev/raw-gadget interface can be blocked by uninterruptible<br /> blocking operations (e.g. mutex_lock()).<br /> <br /> Please also note that (a) and (c) are not addressed. Regarding (c), we<br /> should change the code to wait for only one device which contains the<br /> image for resuming from hibernation. I don&amp;#39;t know how to address (a), for<br /> use of timeout for wait_for_device_probe() might result in loss of user<br /> data in the image. Maybe we should require the userland to wait for the<br /> image device before opening /dev/snapshot interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: Add boundary check in put_entry()<br /> <br /> Just like next_entry(), boundary check is necessary to prevent memory<br /> out-of-bound access.

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.

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