Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panfrost: Fix shrinker list corruption by madvise IOCTL<br /> <br /> Calling madvise IOCTL twice on BO causes memory shrinker list corruption<br /> and crashes kernel because BO is already on the list and it&amp;#39;s added to<br /> the list again, while BO should be removed from the list before it&amp;#39;s<br /> re-added. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix queue selection for mesh/OCB interfaces<br /> <br /> When using iTXQ, the code assumes that there is only one vif queue for<br /> broadcast packets, using the BE queue. Allowing non-BE queue marking<br /> violates that assumption and txq-&gt;ac == skb_queue_mapping is no longer<br /> guaranteed. This can cause issues with queue handling in the driver and<br /> also causes issues with the recent ATF change, resulting in an AQL<br /> underflow warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup: Use separate src/dst nodes when preloading css_sets for migration<br /> <br /> Each cset (css_set) is pinned by its tasks. When we&amp;#39;re moving tasks around<br /> across csets for a migration, we need to hold the source and destination<br /> csets to ensure that they don&amp;#39;t go away while we&amp;#39;re moving tasks about. This<br /> is done by linking cset-&gt;mg_preload_node on either the<br /> mgctx-&gt;preloaded_src_csets or mgctx-&gt;preloaded_dst_csets list. Using the<br /> same cset-&gt;mg_preload_node for both the src and dst lists was deemed okay as<br /> a cset can&amp;#39;t be both the source and destination at the same time.<br /> <br /> Unfortunately, this overloading becomes problematic when multiple tasks are<br /> involved in a migration and some of them are identity noop migrations while<br /> others are actually moving across cgroups. For example, this can happen with<br /> the following sequence on cgroup1:<br /> <br /> #1&gt; mkdir -p /sys/fs/cgroup/misc/a/b<br /> #2&gt; echo $$ &gt; /sys/fs/cgroup/misc/a/cgroup.procs<br /> #3&gt; RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &amp;<br /> #4&gt; PID=$!<br /> #5&gt; echo $PID &gt; /sys/fs/cgroup/misc/a/b/tasks<br /> #6&gt; echo $PID &gt; /sys/fs/cgroup/misc/a/cgroup.procs<br /> <br /> the process including the group leader back into a. In this final migration,<br /> non-leader threads would be doing identity migration while the group leader<br /> is doing an actual one.<br /> <br /> After #3, let&amp;#39;s say the whole process was in cset A, and that after #4, the<br /> leader moves to cset B. Then, during #6, the following happens:<br /> <br /> 1. cgroup_migrate_add_src() is called on B for the leader.<br /> <br /> 2. cgroup_migrate_add_src() is called on A for the other threads.<br /> <br /> 3. cgroup_migrate_prepare_dst() is called. It scans the src list.<br /> <br /> 4. It notices that B wants to migrate to A, so it tries to A to the dst<br /> list but realizes that its -&gt;mg_preload_node is already busy.<br /> <br /> 5. and then it notices A wants to migrate to A as it&amp;#39;s an identity<br /> migration, it culls it by list_del_init()&amp;#39;ing its -&gt;mg_preload_node and<br /> putting references accordingly.<br /> <br /> 6. The rest of migration takes place with B on the src list but nothing on<br /> the dst list.<br /> <br /> This means that A isn&amp;#39;t held while migration is in progress. If all tasks<br /> leave A before the migration finishes and the incoming task pins it, the<br /> cset will be destroyed leading to use-after-free.<br /> <br /> This is caused by overloading cset-&gt;mg_preload_node for both src and dst<br /> preload lists. We wanted to exclude the cset from the src list but ended up<br /> inadvertently excluding it from the dst list too.<br /> <br /> This patch fixes the issue by separating out cset-&gt;mg_preload_node into<br /> -&gt;mg_src_preload_node and -&gt;mg_dst_preload_node, so that the src and dst<br /> preloadings don&amp;#39;t interfere with each other.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/histograms: Fix memory leak problem<br /> <br /> This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.<br /> <br /> As commit 46bbe5c671e0 ("tracing: fix double free") said, the<br /> "double free" problem reported by clang static analyzer is:<br /> &gt; In parse_var_defs() if there is a problem allocating<br /> &gt; var_defs.expr, the earlier var_defs.name is freed.<br /> &gt; This free is duplicated by free_var_defs() which frees<br /> &gt; the rest of the list.<br /> <br /> However, if there is a problem allocating N-th var_defs.expr:<br /> + in parse_var_defs(), the freed &amp;#39;earlier var_defs.name&amp;#39; is<br /> actually the N-th var_defs.name;<br /> + then in free_var_defs(), the names from 0th to (N-1)-th are freed;<br /> <br /> IF ALLOCATING PROBLEM HAPPENED HERE!!! -+<br /> \<br /> |<br /> 0th 1th (N-1)-th N-th V<br /> +-------------+-------------+-----+-------------+-----------<br /> var_defs: | name | expr | name | expr | ... | name | expr | name | ///<br /> +-------------+-------------+-----+-------------+-----------<br /> <br /> These two frees don&amp;#39;t act on same name, so there was no "double free"<br /> problem before. Conversely, after that commit, we get a "memory leak"<br /> problem because the above "N-th var_defs.name" is not freed.<br /> <br /> If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th<br /> var_defs.expr allocated, then execute on shell like:<br /> $ echo &amp;#39;hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc&amp;#39; &gt; \<br /> /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger<br /> <br /> Then kmemleak reports:<br /> unreferenced object 0xffff8fb100ef3518 (size 8):<br /> comm "bash", pid 196, jiffies 4295681690 (age 28.538s)<br /> hex dump (first 8 bytes):<br /> 76 31 00 00 b1 8f ff ff v1......<br /> backtrace:<br /> [] kstrdup+0x2d/0x60<br /> [] event_hist_trigger_parse+0x206f/0x20e0<br /> [] trigger_process_regex+0xc0/0x110<br /> [] event_trigger_write+0x75/0xd0<br /> [] vfs_write+0xbb/0x2a0<br /> [] ksys_write+0x59/0xd0<br /> [] do_syscall_64+0x3a/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: Fix potential memory leak in ima_init_crypto()<br /> <br /> On failure to allocate the SHA1 tfm, IMA fails to initialize and exits<br /> without freeing the ima_algo_array. Add the missing kfree() for<br /> ima_algo_array to avoid the potential memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: fix leaks in probe<br /> <br /> These two error paths should clean up before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nexthop: Fix data-races around nexthop_compat_mode.<br /> <br /> While reading nexthop_compat_mode, it can be changed concurrently.<br /> Thus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix a data-race around sysctl_tcp_ecn_fallback.<br /> <br /> While reading sysctl_tcp_ecn_fallback, it can be changed concurrently.<br /> Thus, we need to add READ_ONCE() to its reader.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> raw: Fix a data-race around sysctl_raw_l3mdev_accept.<br /> <br /> While reading sysctl_raw_l3mdev_accept, it can be changed concurrently.<br /> Thus, we need to add READ_ONCE() to its reader.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> icmp: Fix a data-race around sysctl_icmp_errors_use_inbound_ifaddr.<br /> <br /> While reading sysctl_icmp_errors_use_inbound_ifaddr, it can be changed<br /> concurrently. Thus, we need to add READ_ONCE() to its reader.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> icmp: Fix data-races around sysctl_icmp_echo_enable_probe.<br /> <br /> While reading sysctl_icmp_echo_enable_probe, it can be changed<br /> concurrently. Thus, we need to add READ_ONCE() to its readers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysctl: Fix data-races in proc_dou8vec_minmax().<br /> <br /> A sysctl variable is accessed concurrently, and there is always a chance<br /> of data-race. So, all readers and writers need some basic protection to<br /> avoid load/store-tearing.<br /> <br /> This patch changes proc_dou8vec_minmax() to use READ_ONCE() and<br /> WRITE_ONCE() internally to fix data-races on the sysctl side. For now,<br /> proc_dou8vec_minmax() itself is tolerant to a data-race, but we still<br /> need to add annotations on the other subsystem&amp;#39;s side.