Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_serial: Add null pointer check in gserial_resume<br /> <br /> Consider a case where gserial_disconnect has already cleared<br /> gser-&gt;ioport. And if a wakeup interrupt triggers afterwards,<br /> gserial_resume gets called, which will lead to accessing of<br /> gser-&gt;ioport and thus causing null pointer dereference.Add<br /> a null pointer check to prevent this.<br /> <br /> Added a static spinlock to prevent gser-&gt;ioport from becoming<br /> null after the newly added check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix use-after-free in free_netdev<br /> <br /> We do netif_napi_add() for all allocated q_vectors[], but potentially<br /> do netif_napi_del() for part of them, then kfree q_vectors and leave<br /> invalid pointers at dev-&gt;napi_list.<br /> <br /> Reproducer:<br /> <br /> [root@host ~]# cat repro.sh<br /> #!/bin/bash<br /> <br /> pf_dbsf="0000:41:00.0"<br /> vf0_dbsf="0000:41:02.0"<br /> g_pids=()<br /> <br /> function do_set_numvf()<br /> {<br /> echo 2 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> echo 0 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> }<br /> <br /> function do_set_channel()<br /> {<br /> local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)<br /> [ -z "$nic" ] &amp;&amp; { sleep $((RANDOM%3)) ; return 1; }<br /> ifconfig $nic 192.168.18.5 netmask 255.255.255.0<br /> ifconfig $nic up<br /> ethtool -L $nic combined 1<br /> ethtool -L $nic combined 4<br /> sleep $((RANDOM%3))<br /> }<br /> <br /> function on_exit()<br /> {<br /> local pid<br /> for pid in "${g_pids[@]}"; do<br /> kill -0 "$pid" &amp;&gt;/dev/null &amp;&amp; kill "$pid" &amp;&gt;/dev/null<br /> done<br /> g_pids=()<br /> }<br /> <br /> trap "on_exit; exit" EXIT<br /> <br /> while :; do do_set_numvf ; done &amp;<br /> g_pids+=($!)<br /> while :; do do_set_channel ; done &amp;<br /> g_pids+=($!)<br /> <br /> wait<br /> <br /> Result:<br /> <br /> [ 4093.900222] ==================================================================<br /> [ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390<br /> [ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699<br /> [ 4093.900233]<br /> [ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1<br /> [ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021<br /> [ 4093.900239] Call Trace:<br /> [ 4093.900244] dump_stack+0x71/0xab<br /> [ 4093.900249] print_address_description+0x6b/0x290<br /> [ 4093.900251] ? free_netdev+0x308/0x390<br /> [ 4093.900252] kasan_report+0x14a/0x2b0<br /> [ 4093.900254] free_netdev+0x308/0x390<br /> [ 4093.900261] iavf_remove+0x825/0xd20 [iavf]<br /> [ 4093.900265] pci_device_remove+0xa8/0x1f0<br /> [ 4093.900268] device_release_driver_internal+0x1c6/0x460<br /> [ 4093.900271] pci_stop_bus_device+0x101/0x150<br /> [ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20<br /> [ 4093.900275] pci_iov_remove_virtfn+0x187/0x420<br /> [ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10<br /> [ 4093.900278] ? pci_get_subsys+0x90/0x90<br /> [ 4093.900280] sriov_disable+0xed/0x3e0<br /> [ 4093.900282] ? bus_find_device+0x12d/0x1a0<br /> [ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e]<br /> [ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e]<br /> [ 4093.900299] ? pci_get_device+0x7c/0x90<br /> [ 4093.900300] ? pci_get_subsys+0x90/0x90<br /> [ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210<br /> [ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]<br /> [ 4093.900318] sriov_numvfs_store+0x214/0x290<br /> [ 4093.900320] ? sriov_totalvfs_show+0x30/0x30<br /> [ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 4093.900323] ? __check_object_size+0x15a/0x350<br /> [ 4093.900326] kernfs_fop_write+0x280/0x3f0<br /> [ 4093.900329] vfs_write+0x145/0x440<br /> [ 4093.900330] ksys_write+0xab/0x160<br /> [ 4093.900332] ? __ia32_sys_read+0xb0/0xb0<br /> [ 4093.900334] ? fput_many+0x1a/0x120<br /> [ 4093.900335] ? filp_close+0xf0/0x130<br /> [ 4093.900338] do_syscall_64+0xa0/0x370<br /> [ 4093.900339] ? page_fault+0x8/0x30<br /> [ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> [ 4093.900357] RIP: 0033:0x7f16ad4d22c0<br /> [ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24<br /> [ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0<br /> [ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001<br /> [ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700<br /> [ 4093.9003<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()<br /> <br /> The "exc-&gt;key_len" is a u16 that comes from the user. If it&amp;#39;s over<br /> IW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hyperv: avoid struct memcpy overrun warning<br /> <br /> A previous patch addressed the fortified memcpy warning for most<br /> builds, but I still see this one with gcc-9:<br /> <br /> In file included from include/linux/string.h:254,<br /> from drivers/hid/hid-hyperv.c:8:<br /> In function &amp;#39;fortify_memcpy_chk&amp;#39;,<br /> inlined from &amp;#39;mousevsc_on_receive&amp;#39; at drivers/hid/hid-hyperv.c:272:3:<br /> include/linux/fortify-string.h:583:4: error: call to &amp;#39;__write_overflow_field&amp;#39; declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]<br /> 583 | __write_overflow_field(p_size_field, size);<br /> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> <br /> My guess is that the WARN_ON() itself is what confuses gcc, so it no<br /> longer sees that there is a correct range check. Rework the code in a<br /> way that helps readability and avoids the warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: initialize damo_filter-&gt;list from damos_new_filter()<br /> <br /> damos_new_filter() is not initializing the list field of newly allocated<br /> filter object. However, DAMON sysfs interface and DAMON_RECLAIM are not<br /> initializing it after calling damos_new_filter(). As a result, accessing<br /> uninitialized memory is possible. Actually, adding multiple DAMOS filters<br /> via DAMON sysfs interface caused NULL pointer dereferencing. Initialize<br /> the field just after the allocation from damos_new_filter().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: Rework long task execution when adding/deleting entries<br /> <br /> When adding/deleting large number of elements in one step in ipset, it can<br /> take a reasonable amount of time and can result in soft lockup errors. The<br /> patch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of<br /> consecutive elements to add/delete") tried to fix it by limiting the max<br /> elements to process at all. However it was not enough, it is still possible<br /> that we get hung tasks. Lowering the limit is not reasonable, so the<br /> approach in this patch is as follows: rely on the method used at resizing<br /> sets and save the state when we reach a smaller internal batch limit,<br /> unlock/lock and proceed from the saved state. Thus we can avoid long<br /> continuous tasks and at the same time removed the limit to add/delete large<br /> number of elements in one step.<br /> <br /> The nfnl mutex is held during the whole operation which prevents one to<br /> issue other ipset commands in parallel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: mark requests for GuC virtual engines to avoid use-after-free<br /> <br /> References to i915_requests may be trapped by userspace inside a<br /> sync_file or dmabuf (dma-resv) and held indefinitely across different<br /> proceses. To counter-act the memory leaks, we try to not to keep<br /> references from the request past their completion.<br /> On the other side on fence release we need to know if rq-&gt;engine<br /> is valid and points to hw engine (true for non-virtual requests).<br /> To make it possible extra bit has been added to rq-&gt;execution_mask,<br /> for marking virtual engines.<br /> <br /> (cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: amd-pstate: fix global sysfs attribute type<br /> <br /> In commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()")<br /> the "amd_pstate" attributes where moved from a dedicated kobject to the<br /> cpu root kobject.<br /> <br /> While the dedicated kobject expects to contain kobj_attributes the root<br /> kobject needs device_attributes.<br /> <br /> As the changed arguments are not used by the callbacks it works most of<br /> the time.<br /> However CFI will detect this issue:<br /> <br /> [ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de)<br /> ...<br /> [ 4947.849409] Call Trace:<br /> [ 4947.849410] <br /> [ 4947.849411] ? __warn+0xcf/0x1c0<br /> [ 4947.849414] ? dev_attr_show+0x24/0x60<br /> [ 4947.849415] ? report_cfi_failure+0x4e/0x60<br /> [ 4947.849417] ? handle_cfi_failure+0x14c/0x1d0<br /> [ 4947.849419] ? __cfi_show_status+0x10/0x10<br /> [ 4947.849420] ? handle_bug+0x4f/0x90<br /> [ 4947.849421] ? exc_invalid_op+0x1a/0x60<br /> [ 4947.849422] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 4947.849424] ? __cfi_show_status+0x10/0x10<br /> [ 4947.849425] ? dev_attr_show+0x24/0x60<br /> [ 4947.849426] sysfs_kf_seq_show+0xa6/0x110<br /> [ 4947.849433] seq_read_iter+0x16c/0x4b0<br /> [ 4947.849436] vfs_read+0x272/0x2d0<br /> [ 4947.849438] ksys_read+0x72/0xe0<br /> [ 4947.849439] do_syscall_64+0x76/0xb0<br /> [ 4947.849440] ? do_user_addr_fault+0x252/0x650<br /> [ 4947.849442] ? exc_page_fault+0x7a/0x1b0<br /> [ 4947.849443] entry_SYSCALL_64_after_hwframe+0x72/0xdc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phy<br /> <br /> For some reason, the driver adding support for Exynos5420 MIPI phy<br /> back in 2016 wasn&amp;#39;t used on Exynos5420, which caused a kernel panic.<br /> Add the proper compatible for it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctx<br /> <br /> when mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memory<br /> pointed by &amp;#39;in&amp;#39; is not released, which will cause memory leak. Move memory<br /> release after mlx5_cmd_exec.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: davinci: Fix clk use after free<br /> <br /> The remove function first frees the clks and only then calls<br /> cpufreq_unregister_driver(). If one of the cpufreq callbacks is called<br /> just before cpufreq_unregister_driver() is run, the freed clks might be<br /> used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check<br /> <br /> The vdpa_nl_policy structure is used to validate the nlattr when parsing<br /> the incoming nlmsg. It will ensure the attribute being described produces<br /> a valid nlattr pointer in info-&gt;attrs before entering into each handler<br /> in vdpa_nl_ops.<br /> <br /> That is to say, the missing part in vdpa_nl_policy may lead to illegal<br /> nlattr after parsing, which could lead to OOB read just like CVE-2023-3773.<br /> <br /> This patch adds the missing nla_policy for vdpa max vqp attr to avoid<br /> such bugs.