Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: Add validation for completion descriptors consistency<br /> <br /> Validate that `first` flag is set only for the first<br /> descriptor in multi-buffer packets.<br /> In case of an invalid descriptor, a reset will occur.<br /> A new reset reason for RX data corruption has been added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block/ioctl: prefer different overflow check<br /> <br /> Running syzkaller with the newly reintroduced signed integer overflow<br /> sanitizer shows this report:<br /> <br /> [ 62.982337] ------------[ cut here ]------------<br /> [ 62.985692] cgroup: Invalid name<br /> [ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46<br /> [ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1<br /> [ 62.992992] 9223372036854775807 + 4095 cannot be represented in type &amp;#39;long long&amp;#39;<br /> [ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1<br /> [ 62.999369] random: crng reseeded on system resumption<br /> [ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000)<br /> [ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1<br /> [ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 63.000682] Call Trace:<br /> [ 63.000686] <br /> [ 63.000731] dump_stack_lvl+0x93/0xd0<br /> [ 63.000919] __get_user_pages+0x903/0xd30<br /> [ 63.001030] __gup_longterm_locked+0x153e/0x1ba0<br /> [ 63.001041] ? _raw_read_unlock_irqrestore+0x17/0x50<br /> [ 63.001072] ? try_get_folio+0x29c/0x2d0<br /> [ 63.001083] internal_get_user_pages_fast+0x1119/0x1530<br /> [ 63.001109] iov_iter_extract_pages+0x23b/0x580<br /> [ 63.001206] bio_iov_iter_get_pages+0x4de/0x1220<br /> [ 63.001235] iomap_dio_bio_iter+0x9b6/0x1410<br /> [ 63.001297] __iomap_dio_rw+0xab4/0x1810<br /> [ 63.001316] iomap_dio_rw+0x45/0xa0<br /> [ 63.001328] ext4_file_write_iter+0xdde/0x1390<br /> [ 63.001372] vfs_write+0x599/0xbd0<br /> [ 63.001394] ksys_write+0xc8/0x190<br /> [ 63.001403] do_syscall_64+0xd4/0x1b0<br /> [ 63.001421] ? arch_exit_to_user_mode_prepare+0x3a/0x60<br /> [ 63.001479] entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> [ 63.001535] RIP: 0033:0x7f7fd3ebf539<br /> [ 63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> [ 63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539<br /> [ 63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004<br /> [ 63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000<br /> [ 63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> [ 63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8<br /> ...<br /> [ 63.018142] ---[ end trace ]---<br /> <br /> Historically, the signed integer overflow sanitizer did not work in the<br /> kernel due to its interaction with `-fwrapv` but this has since been<br /> changed [1] in the newest version of Clang; It was re-enabled in the<br /> kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow<br /> sanitizer").<br /> <br /> Let&amp;#39;s rework this overflow checking logic to not actually perform an<br /> overflow during the check itself, thus avoiding the UBSAN splat.<br /> <br /> [1]: https://github.com/llvm/llvm-project/pull/82432

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix UBSAN warning in kv_dpm.c<br /> <br /> Adds bounds check for sumo_vid_mapping_entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: fix UBSAN warning in kv_dpm.c<br /> <br /> Adds bounds check for sumo_vid_mapping_entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Disassociate vcpus from redistributor region on teardown<br /> <br /> When tearing down a redistributor region, make sure we don&amp;#39;t have<br /> any dangling pointer to that region stored in a vcpu.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Add check for srq max_sge attribute<br /> <br /> max_sge attribute is passed by the user, and is inserted and used<br /> unchecked, so verify that the value doesn&amp;#39;t exceed maximum allowed value<br /> before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: Fix suspicious rcu_dereference_protected()<br /> <br /> When destroying all sets, we are either in pernet exit phase or<br /> are executing a "destroy all sets command" from userspace. The latter<br /> was taken into account in ip_set_dereference() (nfnetlink mutex is held),<br /> but the former was not. The patch adds the required check to<br /> rcu_dereference_protected() in ip_set_dereference().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: fix integer overflow in max_vclocks_store<br /> <br /> On 32bit systems, the "4 * max" multiply can overflow. Use kcalloc()<br /> to do the allocation to prevent this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()<br /> <br /> syzbot found hanging tasks waiting on rtnl_lock [1]<br /> <br /> A reproducer is available in the syzbot bug.<br /> <br /> When a request to add multiple actions with the same index is sent, the<br /> second request will block forever on the first request. This holds<br /> rtnl_lock, and causes tasks to hang.<br /> <br /> Return -EAGAIN to prevent infinite looping, while keeping documented<br /> behavior.<br /> <br /> [1]<br /> <br /> INFO: task kworker/1:0:5088 blocked for more than 143 seconds.<br /> Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000<br /> Workqueue: events_power_efficient reg_check_chans_work<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5409 [inline]<br /> __schedule+0xf15/0x5d00 kernel/sched/core.c:6746<br /> __schedule_loop kernel/sched/core.c:6823 [inline]<br /> schedule+0xe7/0x350 kernel/sched/core.c:6838<br /> schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895<br /> __mutex_lock_common kernel/locking/mutex.c:684 [inline]<br /> __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752<br /> wiphy_lock include/net/cfg80211.h:5953 [inline]<br /> reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]<br /> reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Avoid splat in pskb_pull_reason<br /> <br /> syzkaller builds (CONFIG_DEBUG_NET=y) frequently trigger a debug<br /> hint in pskb_may_pull.<br /> <br /> We&amp;#39;d like to retain this debug check because it might hint at integer<br /> overflows and other issues (kernel code should pull headers, not huge<br /> value).<br /> <br /> In bpf case, this splat isn&amp;#39;t interesting at all: such (nonsensical)<br /> bpf programs are typically generated by a fuzzer anyway.<br /> <br /> Do what Eric suggested and suppress such warning.<br /> <br /> For CONFIG_DEBUG_NET=n we don&amp;#39;t need the extra check because<br /> pskb_may_pull will do the right thing: return an error without the<br /> WARN() backtrace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: x86-android-tablets: Unregister devices in reverse order<br /> <br /> Not all subsystems support a device getting removed while there are<br /> still consumers of the device with a reference to the device.<br /> <br /> One example of this is the regulator subsystem. If a regulator gets<br /> unregistered while there are still drivers holding a reference<br /> a WARN() at drivers/regulator/core.c:5829 triggers, e.g.:<br /> <br /> WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister<br /> Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 04/10/2015<br /> RIP: 0010:regulator_unregister<br /> Call Trace:<br /> <br /> regulator_unregister<br /> devres_release_group<br /> i2c_device_remove<br /> device_release_driver_internal<br /> bus_remove_device<br /> device_del<br /> device_unregister<br /> x86_android_tablet_remove<br /> <br /> On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides<br /> a 5V boost converter output for powering USB devices connected to the micro<br /> USB port, the bq24190-charger driver exports this as a Vbus regulator.<br /> <br /> On the 830 (8") and 1050 ("10") models this regulator is controlled by<br /> a platform_device and x86_android_tablet_remove() removes platform_device-s<br /> before i2c_clients so the consumer gets removed first.<br /> <br /> But on the 1380 (13") model there is a lc824206xa micro-USB switch<br /> connected over I2C and the extcon driver for that controls the regulator.<br /> The bq24190 i2c-client *must* be registered first, because that creates<br /> the regulator with the lc824206xa listed as its consumer. If the regulator<br /> has not been registered yet the lc824206xa driver will end up getting<br /> a dummy regulator.<br /> <br /> Since in this case both the regulator provider and consumer are I2C<br /> devices, the only way to ensure that the consumer is unregistered first<br /> is to unregister the I2C devices in reverse order of in which they were<br /> created.<br /> <br /> For consistency and to avoid similar problems in the future change<br /> x86_android_tablet_remove() to unregister all device types in reverse<br /> order.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix kernel crash during resume<br /> <br /> Currently during resume, QMI target memory is not properly handled, resulting<br /> in kernel crash in case DMA remap is not supported:<br /> <br /> BUG: Bad page state in process kworker/u16:54 pfn:36e80<br /> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36e80<br /> page dumped because: nonzero _refcount<br /> Call Trace:<br /> bad_page<br /> free_page_is_bad_report<br /> __free_pages_ok<br /> __free_pages<br /> dma_direct_free<br /> dma_free_attrs<br /> ath12k_qmi_free_target_mem_chunk<br /> ath12k_qmi_msg_mem_request_cb<br /> <br /> The reason is:<br /> Once ath12k module is loaded, firmware sends memory request to host. In case<br /> DMA remap not supported, ath12k refuses the first request due to failure in<br /> allocating with large segment size:<br /> <br /> ath12k_pci 0000:04:00.0: qmi firmware request memory request<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 7077888<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 8454144<br /> ath12k_pci 0000:04:00.0: qmi dma allocation failed (7077888 B type 1), will try later with small size<br /> ath12k_pci 0000:04:00.0: qmi delays mem_request 2<br /> ath12k_pci 0000:04:00.0: qmi firmware request memory request<br /> <br /> Later firmware comes back with more but small segments and allocation<br /> succeeds:<br /> <br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 65536<br /> ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288<br /> <br /> Now ath12k is working. If suspend is triggered, firmware will be reloaded<br /> during resume. As same as before, firmware requests two large segments at<br /> first. In ath12k_qmi_msg_mem_request_cb() segment count and size are<br /> assigned:<br /> <br /> ab-&gt;qmi.mem_seg_count == 2<br /> ab-&gt;qmi.target_mem[0].size == 7077888<br /> ab-&gt;qmi.target_mem[1].size == 8454144<br /> <br /> Then allocation failed like before and ath12k_qmi_free_target_mem_chunk()<br /> is called to free all allocated segments. Note the first segment is skipped<br /> because its v.addr is cleared due to allocation failure:<br /> <br /> chunk-&gt;v.addr = dma_alloc_coherent()<br /> <br /> Also note that this leaks that segment because it has not been freed.<br /> <br /> While freeing the second segment, a size of 8454144 is passed to<br /> dma_free_coherent(). However remember that this segment is allocated at<br /> the first time firmware is loaded, before suspend. So its real size is<br /> 524288, much smaller than 8454144. As a result kernel found we are freeing<br /> some memory which is in use and thus cras<br /> ---truncated---