Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/selftests: fix subtraction overflow bug<br /> <br /> On some machines hole_end can be small enough to cause subtraction<br /> overflow. On the other side (addr + 2 * min_alignment) can overflow<br /> in case of mock tests. This patch should handle both cases.<br /> <br /> (cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vlan: fix memory leak in vlan_newlink()<br /> <br /> Blamed commit added back a bug I fixed in commit 9bbd917e0bec<br /> ("vlan: fix memory leak in vlan_dev_set_egress_priority")<br /> <br /> If a memory allocation fails in vlan_changelink() after other allocations<br /> succeeded, we need to call vlan_dev_free_egress_priority()<br /> to free all allocated memory because after a failed -&gt;newlink()<br /> we do not call any methods like ndo_uninit() or dev-&gt;priv_destructor().<br /> <br /> In following example, if the allocation for last element 2000:2001 fails,<br /> we need to free eight prior allocations:<br /> <br /> ip link add link dummy0 dummy0.100 type vlan id 100 \<br /> egress-qos-map 1:2 2:3 3:4 4:5 5:6 6:7 7:8 8:9 2000:2001<br /> <br /> syzbot report was:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888117bd1060 (size 32):<br /> comm "syz-executor408", pid 3759, jiffies 4294956555 (age 34.090s)<br /> hex dump (first 32 bytes):<br /> 09 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc include/linux/slab.h:600 [inline]<br /> [] vlan_dev_set_egress_priority+0xed/0x170 net/8021q/vlan_dev.c:193<br /> [] vlan_changelink+0x178/0x1d0 net/8021q/vlan_netlink.c:128<br /> [] vlan_newlink+0x148/0x260 net/8021q/vlan_netlink.c:185<br /> [] rtnl_newlink_create net/core/rtnetlink.c:3363 [inline]<br /> [] __rtnl_newlink+0xa58/0xdc0 net/core/rtnetlink.c:3580<br /> [] rtnl_newlink+0x49/0x70 net/core/rtnetlink.c:3593<br /> [] rtnetlink_rcv_msg+0x21c/0x5c0 net/core/rtnetlink.c:6089<br /> [] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2501<br /> [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345<br /> [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921<br /> [] sock_sendmsg_nosec net/socket.c:714 [inline]<br /> [] sock_sendmsg+0x56/0x80 net/socket.c:734<br /> [] ____sys_sendmsg+0x36c/0x390 net/socket.c:2488<br /> [] ___sys_sendmsg+0x8b/0xd0 net/socket.c:2542<br /> [] __sys_sendmsg net/socket.c:2571 [inline]<br /> [] __do_sys_sendmsg net/socket.c:2580 [inline]<br /> [] __se_sys_sendmsg net/socket.c:2578 [inline]<br /> [] __x64_sys_sendmsg+0x78/0xf0 net/socket.c:2578<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

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