Vulnerabilities

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 /> 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: ocmem: Fix refcount leak in of_get_ocmem<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> of_node_put() will check NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: zynq: Fix refcount leak in zynq_get_revision<br /> <br /> of_find_compatible_node() returns a node pointer with refcount<br /> 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 /> ARM: OMAP2+: Fix refcount leak in omap3xxx_prm_late_init<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: OMAP2+: Fix refcount leak in omapdss_init_of<br /> <br /> omapdss_find_dss_of_node() calls of_find_compatible_node() to get device<br /> node. of_find_compatible_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() in later error path and normal path.

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