Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: add missing -&gt;fini_microcode interface for Sienna Cichlid<br /> <br /> To avoid any potential memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: add missing -&gt;fini_xxxx interfaces for some SMU13 asics<br /> <br /> Without these, potential memory leak may be induced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level<br /> <br /> Though acpi_find_last_cache_level() always returned signed value and the<br /> document states it will return any errors caused by lack of a PPTT table,<br /> it never returned negative values before.<br /> <br /> Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")<br /> however changed it by returning -ENOENT if no PPTT was found. The value<br /> returned from acpi_find_last_cache_level() is then assigned to unsigned<br /> fw_level.<br /> <br /> It will result in the number of cache leaves calculated incorrectly as<br /> a huge value which will then cause the following warning from __alloc_pages<br /> as the order would be great than MAX_ORDER because of incorrect and huge<br /> cache leaves value.<br /> <br /> | WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314<br /> | Modules linked in:<br /> | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73<br /> | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : __alloc_pages+0x74/0x314<br /> | lr : alloc_pages+0xe8/0x318<br /> | Call trace:<br /> | __alloc_pages+0x74/0x314<br /> | alloc_pages+0xe8/0x318<br /> | kmalloc_order_trace+0x68/0x1dc<br /> | __kmalloc+0x240/0x338<br /> | detect_cache_attributes+0xe0/0x56c<br /> | update_siblings_masks+0x38/0x284<br /> | store_cpu_topology+0x78/0x84<br /> | smp_prepare_cpus+0x48/0x134<br /> | kernel_init_freeable+0xc4/0x14c<br /> | kernel_init+0x2c/0x1b4<br /> | ret_from_fork+0x10/0x20<br /> <br /> Fix the same by changing fw_level to be signed integer and return the<br /> error from init_cache_level() early in case of error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/ttm: fix CCS handling<br /> <br /> Crucible + recent Mesa seems to sometimes hit:<br /> <br /> GEM_BUG_ON(num_ccs_blks &gt; NUM_CCS_BLKS_PER_XFER)<br /> <br /> And it looks like we can also trigger this with gem_lmem_swapping, if we<br /> modify the test to use slightly larger object sizes.<br /> <br /> Looking closer it looks like we have the following issues in<br /> migrate_copy():<br /> <br /> - We are using plain integer in various places, which we can easily<br /> overflow with a large object.<br /> <br /> - We pass the entire object size (when the src is lmem) into<br /> emit_pte() and then try to copy it, which doesn&amp;#39;t work, since we<br /> only have a few fixed sized windows in which to map the pages and<br /> perform the copy. With an object &gt; 8M we therefore aren&amp;#39;t properly<br /> copying the pages. And then with an object &gt; 64M we trigger the<br /> GEM_BUG_ON(num_ccs_blks &gt; NUM_CCS_BLKS_PER_XFER).<br /> <br /> So it looks like our copy handling for any object &gt; 8M (which is our<br /> CHUNK_SZ) is currently broken on DG2.<br /> <br /> Testcase: igt@gem_lmem_swapping<br /> (cherry picked from commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Fix null pointer dereference in remove if xHC has only one roothub<br /> <br /> The remove path in xhci platform driver tries to remove and put both main<br /> and shared hcds even if only a main hcd exists (one roothub)<br /> <br /> This causes a null pointer dereference in reboot for those controllers.<br /> <br /> Check that the shared_hcd exists before trying to remove it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO<br /> <br /> Precision markers need to be propagated whenever we have an ARG_CONST_*<br /> style argument, as the verifier cannot consider imprecise scalars to be<br /> equivalent for the purposes of states_equal check when such arguments<br /> refine the return value (in this case, set mem_size for PTR_TO_MEM). The<br /> resultant mem_size for the R0 is derived from the constant value, and if<br /> the verifier incorrectly prunes states considering them equivalent where<br /> such arguments exist (by seeing that both registers have reg-&gt;precise as<br /> false in regsafe), we can end up with invalid programs passing the<br /> verifier which can do access beyond what should have been the correct<br /> mem_size in that explored state.<br /> <br /> To show a concrete example of the problem:<br /> <br /> 0000000000000000 :<br /> 0: r2 = *(u32 *)(r1 + 80)<br /> 1: r1 = *(u32 *)(r1 + 76)<br /> 2: r3 = r1<br /> 3: r3 += 4<br /> 4: if r3 &gt; r2 goto +18 <br /> 5: w2 = 0<br /> 6: *(u32 *)(r1 + 0) = r2<br /> 7: r1 = *(u32 *)(r1 + 0)<br /> 8: r2 = 1<br /> 9: if w1 == 0 goto +1 <br /> 10: r2 = -1<br /> <br /> 0000000000000058 :<br /> 11: r1 = 0 ll<br /> 13: r3 = 0<br /> 14: call bpf_ringbuf_reserve<br /> 15: if r0 == 0 goto +7 <br /> 16: r1 = r0<br /> 17: r1 += 16777215<br /> 18: w2 = 0<br /> 19: *(u8 *)(r1 + 0) = r2<br /> 20: r1 = r0<br /> 21: r2 = 0<br /> 22: call bpf_ringbuf_submit<br /> <br /> 00000000000000b8 :<br /> 23: w0 = 0<br /> 24: exit<br /> <br /> For the first case, the single line execution&amp;#39;s exploration will prune<br /> the search at insn 14 for the branch insn 9&amp;#39;s second leg as it will be<br /> verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will<br /> always be 0 so at runtime we don&amp;#39;t get error for being greater than<br /> UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just<br /> sees reg-&gt;precise as false for both r2 registers in both states, hence<br /> considers them equal for purposes of states_equal.<br /> <br /> If we propagated precise markers using the backtracking support, we<br /> would use the precise marking to then ensure that old r2 (UINT_MAX) was<br /> within the new r2 (1) and this would never be true, so the verification<br /> would rightfully fail.<br /> <br /> The end result is that the out of bounds access at instruction 19 would<br /> be permitted without this fix.<br /> <br /> Note that reg-&gt;precise is always set to true when user does not have<br /> CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static<br /> or global functions)), hence this is only a problem when precision marks<br /> need to be explicitly propagated (i.e. privileged users with CAP_BPF).<br /> <br /> A simplified test case has been included in the next patch to prevent<br /> future regressions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: fix null pointer dereference<br /> <br /> Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.<br /> The root cause is null pointer defeference of bi_next<br /> in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000002e<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G U 5.17.0-rc1<br /> Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021<br /> RIP: 0010:tgl_get_bw_info+0x2de/0x510<br /> ...<br /> [ 2.554467] Call Trace:<br /> [ 2.554467] <br /> [ 2.554467] intel_bw_init_hw+0x14a/0x434<br /> [ 2.554467] ? _printk+0x59/0x73<br /> [ 2.554467] ? _dev_err+0x77/0x91<br /> [ 2.554467] i915_driver_hw_probe+0x329/0x33e<br /> [ 2.554467] i915_driver_probe+0x4c8/0x638<br /> [ 2.554467] i915_pci_probe+0xf8/0x14e<br /> [ 2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c<br /> [ 2.554467] pci_device_probe+0xaa/0x142<br /> [ 2.554467] really_probe+0x13f/0x2f4<br /> [ 2.554467] __driver_probe_device+0x9e/0xd3<br /> [ 2.554467] driver_probe_device+0x24/0x7c<br /> [ 2.554467] __driver_attach+0xba/0xcf<br /> [ 2.554467] ? driver_attach+0x1f/0x1f<br /> [ 2.554467] bus_for_each_dev+0x8c/0xc0<br /> [ 2.554467] bus_add_driver+0x11b/0x1f7<br /> [ 2.554467] driver_register+0x60/0xea<br /> [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16<br /> [ 2.554467] i915_init+0x2c/0xb9<br /> [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16<br /> [ 2.554467] do_one_initcall+0x12e/0x2b3<br /> [ 2.554467] do_initcall_level+0xd6/0xf3<br /> [ 2.554467] do_initcalls+0x4e/0x79<br /> [ 2.554467] kernel_init_freeable+0xed/0x14d<br /> [ 2.554467] ? rest_init+0xc1/0xc1<br /> [ 2.554467] kernel_init+0x1a/0x120<br /> [ 2.554467] ret_from_fork+0x1f/0x30<br /> [ 2.554467] <br /> ...<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> (cherry picked from commit c247cd03898c4c43c3bce6d4014730403bc13032)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: fix memory leak at failed datapath creation<br /> <br /> ovs_dp_cmd_new()-&gt;ovs_dp_change()-&gt;ovs_dp_set_upcall_portids()<br /> allocates array via kmalloc.<br /> If for some reason new_vport() fails during ovs_dp_cmd_new()<br /> dp-&gt;upcall_portids must be freed.<br /> Add missing kfree.<br /> <br /> Kmemleak example:<br /> unreferenced object 0xffff88800c382500 (size 64):<br /> comm "dump_state", pid 323, jiffies 4294955418 (age 104.347s)<br /> hex dump (first 32 bytes):<br /> 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8.....<br /> 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(...<br /> backtrace:<br /> [] ovs_dp_set_upcall_portids+0x38/0xa0<br /> [] ovs_dp_change+0x63/0xe0<br /> [] ovs_dp_cmd_new+0x1f0/0x380<br /> [] genl_family_rcv_msg_doit+0xea/0x150<br /> [] genl_rcv_msg+0xdc/0x1e0<br /> [] netlink_rcv_skb+0x50/0x100<br /> [] genl_rcv+0x24/0x40<br /> [] netlink_unicast+0x23e/0x360<br /> [] netlink_sendmsg+0x24e/0x4b0<br /> [] sock_sendmsg+0x62/0x70<br /> [] ____sys_sendmsg+0x230/0x270<br /> [] ___sys_sendmsg+0x88/0xd0<br /> [] __sys_sendmsg+0x59/0xa0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: fix netdevice reference leaks in attach_default_qdiscs()<br /> <br /> In attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails<br /> to attach qdisc because there is no memory in attach_one_default_qdisc().<br /> Then dev-&gt;qdisc will be noop_qdisc by default. But the other queues may be<br /> able to successfully attach to default qdisc.<br /> <br /> In this case, the fallback to noqueue process will be triggered. If the<br /> original attached qdisc is not released and a new one is directly<br /> attached, this will cause netdevice reference leaks.<br /> <br /> The following is the bug log:<br /> <br /> veth0: default qdisc (fq_codel) fail, fallback to noqueue<br /> unregister_netdevice: waiting for veth0 to become free. Usage count = 32<br /> leaked reference.<br /> qdisc_alloc+0x12e/0x210<br /> qdisc_create_dflt+0x62/0x140<br /> attach_one_default_qdisc.constprop.41+0x44/0x70<br /> dev_activate+0x128/0x290<br /> __dev_open+0x12a/0x190<br /> __dev_change_flags+0x1a2/0x1f0<br /> dev_change_flags+0x23/0x60<br /> do_setlink+0x332/0x1150<br /> __rtnl_newlink+0x52f/0x8e0<br /> rtnl_newlink+0x43/0x70<br /> rtnetlink_rcv_msg+0x140/0x3b0<br /> netlink_rcv_skb+0x50/0x100<br /> netlink_unicast+0x1bb/0x290<br /> netlink_sendmsg+0x37c/0x4e0<br /> sock_sendmsg+0x5f/0x70<br /> ____sys_sendmsg+0x208/0x280<br /> <br /> Fix this bug by clearing any non-noop qdiscs that may have been assigned<br /> before trying to re-attach.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware_loader: Fix use-after-free during unregister<br /> <br /> In the following code within firmware_upload_unregister(), the call to<br /> device_unregister() could result in the dev_release function freeing the<br /> fw_upload_priv structure before it is dereferenced for the call to<br /> module_put(). This bug was found by the kernel test robot using<br /> CONFIG_KASAN while running the firmware selftests.<br /> <br /> device_unregister(&amp;fw_sysfs-&gt;dev);<br /> module_put(fw_upload_priv-&gt;module);<br /> <br /> The problem is fixed by copying fw_upload_priv-&gt;module to a local variable<br /> for use when calling device_unregister().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix memory corruption on probe<br /> <br /> Add the missing sanity check on the probed-session count to avoid<br /> corrupting memory beyond the fixed-size slab-allocated session array<br /> when there are more than FASTRPC_MAX_SESSIONS sessions defined in the<br /> devicetree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: cm3605: Fix an error handling path in cm3605_probe()<br /> <br /> The commit in Fixes also introduced a new error handling path which should<br /> goto the existing error handling path.<br /> Otherwise some resources leak.