Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK<br /> <br /> When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,<br /> cpu_max_bits_warn() generates a runtime warning similar as below while<br /> we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)<br /> instead of NR_CPUS to iterate CPUs.<br /> <br /> [ 3.052463] ------------[ cut here ]------------<br /> [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0<br /> [ 3.070072] Modules linked in: efivarfs autofs4<br /> [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052<br /> [ 3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27<br /> [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000<br /> [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430<br /> [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff<br /> [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890<br /> [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa<br /> [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000<br /> [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000<br /> [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000<br /> [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286<br /> [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c<br /> [ 3.195868] ...<br /> [ 3.199917] Call Trace:<br /> [ 3.203941] [] show_stack+0x38/0x14c<br /> [ 3.210666] [] dump_stack_lvl+0x60/0x88<br /> [ 3.217625] [] __warn+0xd0/0x100<br /> [ 3.223958] [] warn_slowpath_fmt+0x7c/0xcc<br /> [ 3.231150] [] show_cpuinfo+0x5e8/0x5f0<br /> [ 3.238080] [] seq_read_iter+0x354/0x4b4<br /> [ 3.245098] [] new_sync_read+0x17c/0x1c4<br /> [ 3.252114] [] vfs_read+0x138/0x1d0<br /> [ 3.258694] [] ksys_read+0x70/0x100<br /> [ 3.265265] [] do_syscall+0x7c/0x94<br /> [ 3.271820] [] handle_syscall+0xc4/0x160<br /> [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_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 /> soc: amlogic: Fix refcount leak in meson-secure-pwrc.c<br /> <br /> In meson_secure_pwrc_probe(), there is a refcount leak in one fail<br /> path.

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