Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: Set lower bound of start tick time<br /> <br /> Currently ALSA timer doesn&amp;#39;t have the lower limit of the start tick<br /> time, and it allows a very small size, e.g. 1 tick with 1ns resolution<br /> for hrtimer. Such a situation may lead to an unexpected RCU stall,<br /> where the callback repeatedly queuing the expire update, as reported<br /> by fuzzer.<br /> <br /> This patch introduces a sanity check of the timer start tick time, so<br /> that the system returns an error when a too small start size is set.<br /> As of this patch, the lower limit is hard-coded to 100us, which is<br /> small enough but can still work somehow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: Fix reference count leak issues of ax25_dev<br /> <br /> The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference<br /> count leak issue of the object "ax25_dev".<br /> <br /> Memory leak issue in ax25_addr_ax25dev():<br /> <br /> The reference count of the object "ax25_dev" can be increased multiple<br /> times in ax25_addr_ax25dev(). This will cause a memory leak.<br /> <br /> Memory leak issues in ax25_dev_device_down():<br /> <br /> The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and<br /> then increase the reference count when ax25_dev is added to ax25_dev_list.<br /> As a result, the reference count of ax25_dev is 2. But when the device is<br /> shutting down. The ax25_dev_device_down() drops the reference count once<br /> or twice depending on if we goto unlock_put or not, which will cause<br /> memory leak.<br /> <br /> As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer<br /> to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the<br /> issue of ax25_dev_device_down(), increase the reference count of ax25_dev<br /> once in ax25_dev_device_up() and decrease the reference count of ax25_dev<br /> after it is removed from the ax25_dev_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()<br /> <br /> pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()<br /> fails, the irq vector is not freed, which leads to a memory leak.<br /> <br /> Replace the devm_add_action with devm_add_action_or_reset to ensure<br /> the irq vector can be destroyed when it fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: refine the EOF check in blkdev_iomap_begin<br /> <br /> blkdev_iomap_begin rounds down the offset to the logical block size<br /> before stashing it in iomap-&gt;offset and checking that it still is<br /> inside the inode size.<br /> <br /> Check the i_size check to the raw pos value so that we don&amp;#39;t try a<br /> zero size write if iter-&gt;pos is unaligned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: core: Fix NULL module pointer assignment at card init<br /> <br /> The commit 81033c6b584b ("ALSA: core: Warn on empty module")<br /> introduced a WARN_ON() for a NULL module pointer passed at snd_card<br /> object creation, and it also wraps the code around it with &amp;#39;#ifdef<br /> MODULE&amp;#39;. This works in most cases, but the devils are always in<br /> details. "MODULE" is defined when the target code (i.e. the sound<br /> core) is built as a module; but this doesn&amp;#39;t mean that the caller is<br /> also built-in or not. Namely, when only the sound core is built-in<br /> (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),<br /> the passed module pointer is ignored even if it&amp;#39;s non-NULL, and<br /> card-&gt;module remains as NULL. This would result in the missing module<br /> reference up/down at the device open/close, leading to a race with the<br /> code execution after the module removal.<br /> <br /> For addressing the bug, move the assignment of card-&gt;module again out<br /> of ifdef. The WARN_ON() is still wrapped with ifdef because the<br /> module can be really NULL when all sound drivers are built-in.<br /> <br /> Note that we keep &amp;#39;ifdef MODULE&amp;#39; for WARN_ON(), otherwise it would<br /> lead to a false-positive NULL module check. Admittedly it won&amp;#39;t catch<br /> perfectly, i.e. no check is performed when CONFIG_SND=y. But, it&amp;#39;s no<br /> real problem as it&amp;#39;s only for debugging, and the condition is pretty<br /> rare.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - validate slices count returned by FW<br /> <br /> The function adf_send_admin_tl_start() enables the telemetry (TL)<br /> feature on a QAT device by sending the ICP_QAT_FW_TL_START message to<br /> the firmware. This triggers the FW to start writing TL data to a DMA<br /> buffer in memory and returns an array containing the number of<br /> accelerators of each type (slices) supported by this HW.<br /> The pointer to this array is stored in the adf_tl_hw_data data<br /> structure called slice_cnt.<br /> <br /> The array slice_cnt is then used in the function tl_print_dev_data()<br /> to report in debugfs only statistics about the supported accelerators.<br /> An incorrect value of the elements in slice_cnt might lead to an out<br /> of bounds memory read.<br /> At the moment, there isn&amp;#39;t an implementation of FW that returns a wrong<br /> value, but for robustness validate the slice count array returned by FW.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"<br /> <br /> The via-macii ADB driver calls request_irq() after disabling hard<br /> interrupts. But disabling interrupts isn&amp;#39;t necessary here because the<br /> VIA shift register interrupt was masked during VIA1 initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix netif state handling<br /> <br /> mlx5e_suspend cleans resources only if netif_device_present() returns<br /> true. However, mlx5e_resume changes the state of netif, via<br /> mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.<br /> In the below case, the above leads to NULL-ptr Oops[1] and memory<br /> leaks:<br /> <br /> mlx5e_probe<br /> _mlx5e_resume<br /> mlx5e_attach_netdev<br /> mlx5e_nic_enable

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: connac: check for null before dereferencing<br /> <br /> The wcid can be NULL. It should be checked for validity before<br /> dereferencing it to avoid crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()<br /> <br /> Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes".<br /> <br /> Patch #1 fixes a bunch of issues I spotted in the acrn driver. It<br /> compiles, that&amp;#39;s all I know. I&amp;#39;ll appreciate some review and testing from<br /> acrn folks.<br /> <br /> Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding<br /> more sanity checks, and improving the documentation. Gave it a quick test<br /> on x86-64 using VM_PAT that ends up using follow_pte().<br /> <br /> <br /> This patch (of 3):<br /> <br /> We currently miss handling various cases, resulting in a dangerous<br /> follow_pte() (previously follow_pfn()) usage.<br /> <br /> (1) We&amp;#39;re not checking PTE write permissions.<br /> <br /> Maybe we should simply always require pte_write() like we do for<br /> pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let&amp;#39;s check for<br /> ACRN_MEM_ACCESS_WRITE for now.<br /> <br /> (2) We&amp;#39;re not rejecting refcounted pages.<br /> <br /> As we are not using MMU notifiers, messing with refcounted pages is<br /> dangerous and can result in use-after-free. Let&amp;#39;s make sure to reject them.<br /> <br /> (3) We are only looking at the first PTE of a bigger range.<br /> <br /> We only lookup a single PTE, but memmap-&gt;len may span a larger area.<br /> Let&amp;#39;s loop over all involved PTEs and make sure the PFN range is<br /> actually contiguous. Reject everything else: it couldn&amp;#39;t have worked<br /> either way, and rather made use access PFNs we shouldn&amp;#39;t be accessing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Fix a race between readers and resize checks<br /> <br /> The reader code in rb_get_reader_page() swaps a new reader page into the<br /> ring buffer by doing cmpxchg on old-&gt;list.prev-&gt;next to point it to the<br /> new page. Following that, if the operation is successful,<br /> old-&gt;list.next-&gt;prev gets updated too. This means the underlying<br /> doubly-linked list is temporarily inconsistent, page-&gt;prev-&gt;next or<br /> page-&gt;next-&gt;prev might not be equal back to page for some page in the<br /> ring buffer.<br /> <br /> The resize operation in ring_buffer_resize() can be invoked in parallel.<br /> It calls rb_check_pages() which can detect the described inconsistency<br /> and stop further tracing:<br /> <br /> [ 190.271762] ------------[ cut here ]------------<br /> [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0<br /> [ 190.271789] Modules linked in: [...]<br /> [ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1<br /> [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f<br /> [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014<br /> [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0<br /> [ 190.272023] Code: [...]<br /> [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206<br /> [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80<br /> [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700<br /> [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000<br /> [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720<br /> [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000<br /> [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000<br /> [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0<br /> [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 190.272077] Call Trace:<br /> [ 190.272098] <br /> [ 190.272189] ring_buffer_resize+0x2ab/0x460<br /> [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0<br /> [ 190.272206] tracing_resize_ring_buffer+0x65/0x90<br /> [ 190.272216] tracing_entries_write+0x74/0xc0<br /> [ 190.272225] vfs_write+0xf5/0x420<br /> [ 190.272248] ksys_write+0x67/0xe0<br /> [ 190.272256] do_syscall_64+0x82/0x170<br /> [ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 190.272373] RIP: 0033:0x7f1bd657d263<br /> [ 190.272381] Code: [...]<br /> [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263<br /> [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001<br /> [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000<br /> [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500<br /> [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002<br /> [ 190.272412] <br /> [ 190.272414] ---[ end trace 0000000000000000 ]---<br /> <br /> Note that ring_buffer_resize() calls rb_check_pages() only if the parent<br /> trace_buffer has recording disabled. Recent commit d78ab792705c<br /> ("tracing: Stop current tracer when resizing buffer") causes that it is<br /> now always the case which makes it more likely to experience this issue.<br /> <br /> The window to hit this race is nonetheless very small. To help<br /> reproducing it, one can add a delay loop in rb_get_reader_page():<br /> <br /> ret = rb_head_page_replace(reader, cpu_buffer-&gt;reader_page);<br /> if (!ret)<br /> goto spin;<br /> for (unsigned i = 0; i reader_page-&gt;list;<br /> <br /> .. <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: et8ek8: Don&amp;#39;t strip remove function when driver is builtin<br /> <br /> Using __exit for the remove function results in the remove callback<br /> being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets<br /> unbound (e.g. using sysfs or hotplug), the driver is just removed<br /> without the cleanup being performed. This results in resource leaks. Fix<br /> it by compiling in the remove callback unconditionally.<br /> <br /> This also fixes a W=1 modpost warning:<br /> <br /> WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -&gt; et8ek8_remove (section: .exit.text)