Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setup<br /> <br /> variable *nplanes is provided by user via system call argument. The<br /> possible value of q_data-&gt;fmt-&gt;num_planes is 1-3, while the value<br /> of *nplanes can be 1-8. The array access by index i can cause array<br /> out-of-bounds.<br /> <br /> Fix this bug by checking *nplanes against the array size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: fix clear_user_rep_good() exception handling annotation<br /> <br /> This code no longer exists in mainline, because it was removed in<br /> commit d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory<br /> clearing") upstream.<br /> <br /> However, rather than backport the full range of x86 memory clearing and<br /> copying cleanups, fix the exception table annotation placement for the<br /> final &amp;#39;rep movsb&amp;#39; in clear_user_rep_good(): rather than pointing at the<br /> actual instruction that did the user space access, it pointed to the<br /> register move just before it.<br /> <br /> That made sense from a code flow standpoint, but not from an actual<br /> usage standpoint: it means that if user access takes an exception, the<br /> exception handler won&amp;#39;t actually find the instruction in the exception<br /> tables.<br /> <br /> As a result, rather than fixing it up and returning -EFAULT, it would<br /> then turn it into a kernel oops report instead, something like:<br /> <br /> BUG: unable to handle page fault for address: 0000000020081000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> ...<br /> RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147<br /> ...<br /> Call Trace:<br /> __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]<br /> clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]<br /> iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800<br /> iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]<br /> iomap_dio_iter fs/iomap/direct-io.c:440 [inline]<br /> __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601<br /> iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689<br /> ext4_dio_read_iter fs/ext4/file.c:94 [inline]<br /> ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145<br /> call_read_iter include/linux/fs.h:2183 [inline]<br /> do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733<br /> do_iter_read+0x2f2/0x750 fs/read_write.c:796<br /> vfs_readv+0xe5/0x150 fs/read_write.c:916<br /> do_preadv+0x1b6/0x270 fs/read_write.c:1008<br /> __do_sys_preadv2 fs/read_write.c:1070 [inline]<br /> __se_sys_preadv2 fs/read_write.c:1061 [inline]<br /> __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> which then looks like a filesystem bug rather than the incorrect<br /> exception annotation that it is.<br /> <br /> [ The alternative to this one-liner fix is to take the upstream series<br /> that cleans this all up:<br /> <br /> 68674f94ffc9 ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory copies")<br /> 20f3337d350c ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory clearing")<br /> adfcf4231b8c ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory copies")<br /> * d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory clearing")<br /> 3639a535587d ("x86: move stac/clac from user copy routines into callers")<br /> 577e6a7fd50d ("x86: inline the &amp;#39;rep movs&amp;#39; in user copies for the FSRM case")<br /> 8c9b6a88b7e2 ("x86: improve on the non-rep &amp;#39;clear_user&amp;#39; function")<br /> 427fda2c8a49 ("x86: improve on the non-rep &amp;#39;copy_user&amp;#39; function")<br /> * e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM")<br /> e1f2750edc4a ("x86: remove &amp;#39;zerorest&amp;#39; argument from __copy_user_nocache()")<br /> 034ff37d3407 ("x86: rewrite &amp;#39;__copy_user_nocache&amp;#39; function")<br /> <br /> with either the whole series or at a minimum the two marked commits<br /> being needed to fix this issue ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: freescale: Fix a memory out of bounds when num_configs is 1<br /> <br /> The config passed in by pad wakeup is 1, when num_configs is 1,<br /> Configuration [1] should not be fetched, which will be detected<br /> by KASAN as a memory out of bounds condition. Modify to get<br /> configs[1] when num_configs is 2.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix potential use-after-free bugs in TCP_Server_Info::hostname<br /> <br /> TCP_Server_Info::hostname may be updated once or many times during<br /> reconnect, so protect its access outside reconnect path as well and<br /> then prevent any potential use-after-free bugs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: deal with integer overflows in kmalloc_reserve()<br /> <br /> Blamed commit changed:<br /> ptr = kmalloc(size);<br /> if (ptr)<br /> size = ksize(ptr);<br /> <br /> size = kmalloc_size_roundup(size);<br /> ptr = kmalloc(size);<br /> <br /> This allowed various crash as reported by syzbot [1]<br /> and Kyle Zeng.<br /> <br /> Problem is that if @size is bigger than 0x80000001,<br /> kmalloc_size_roundup(size) returns 2^32.<br /> <br /> kmalloc_reserve() uses a 32bit variable (obj_size),<br /> so 2^32 is truncated to 0.<br /> <br /> kmalloc(0) returns ZERO_SIZE_PTR which is not handled by<br /> skb allocations.<br /> <br /> Following trace can be triggered if a netdev-&gt;mtu is set<br /> close to 0x7fffffff<br /> <br /> We might in the future limit netdev-&gt;mtu to more sensible<br /> limit (like KMALLOC_MAX_SIZE).<br /> <br /> This patch is based on a syzbot report, and also a report<br /> and tentative fix from Kyle Zeng.<br /> <br /> [1]<br /> BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]<br /> BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527<br /> Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554<br /> <br /> CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023<br /> Call trace:<br /> dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286<br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106<br /> print_report+0xe4/0x4b4 mm/kasan/report.c:398<br /> kasan_report+0x150/0x1ac mm/kasan/report.c:495<br /> kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189<br /> memset+0x40/0x70 mm/kasan/shadow.c:44<br /> __build_skb_around net/core/skbuff.c:294 [inline]<br /> __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527<br /> alloc_skb include/linux/skbuff.h:1316 [inline]<br /> igmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359<br /> add_grec+0x81c/0x1124 net/ipv4/igmp.c:534<br /> igmpv3_send_cr net/ipv4/igmp.c:667 [inline]<br /> igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810<br /> call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474<br /> expire_timers kernel/time/timer.c:1519 [inline]<br /> __run_timers+0x54c/0x710 kernel/time/timer.c:1790<br /> run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803<br /> _stext+0x380/0xfbc<br /> ____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79<br /> call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891<br /> do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84<br /> invoke_softirq kernel/softirq.c:437 [inline]<br /> __irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683<br /> irq_exit_rcu+0x14/0x78 kernel/softirq.c:695<br /> el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717<br /> __el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724<br /> el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729<br /> el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix mapping to non-allocated address<br /> <br /> [Why]<br /> There is an issue mapping non-allocated location of memory.<br /> It would allocate gpio registers from an array out of bounds.<br /> <br /> [How]<br /> Patch correct numbers of bounds for using.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix ioremap issues in lpfc_sli4_pci_mem_setup()<br /> <br /> When if_type equals zero and pci_resource_start(pdev, PCI_64BIT_BAR4)<br /> returns false, drbl_regs_memmap_p is not remapped. This passes a NULL<br /> pointer to iounmap(), which can trigger a WARN() on certain arches.<br /> <br /> When if_type equals six and pci_resource_start(pdev, PCI_64BIT_BAR4)<br /> returns true, drbl_regs_memmap_p may has been remapped and<br /> ctrl_regs_memmap_p is not remapped. This is a resource leak and passes a<br /> NULL pointer to iounmap().<br /> <br /> To fix these issues, we need to add null checks before iounmap(), and<br /> change some goto labels.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rsi: Fix memory leak in rsi_coex_attach()<br /> <br /> The coex_cb needs to be freed when rsi_create_kthread() failed in<br /> rsi_coex_attach().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: hugetlb: fix UAF in hugetlb_handle_userfault<br /> <br /> The vma_lock and hugetlb_fault_mutex are dropped before handling userfault<br /> and reacquire them again after handle_userfault(), but reacquire the<br /> vma_lock could lead to UAF[1,2] due to the following race,<br /> <br /> hugetlb_fault<br /> hugetlb_no_page<br /> /*unlock vma_lock */<br /> hugetlb_handle_userfault<br /> handle_userfault<br /> /* unlock mm-&gt;mmap_lock*/<br /> vm_mmap_pgoff<br /> do_mmap<br /> mmap_region<br /> munmap_vma_range<br /> /* clean old vma */<br /> /* lock vma_lock again

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcsan: Avoid READ_ONCE() in read_instrumented_memory()<br /> <br /> Haibo Li reported:<br /> <br /> | Unable to handle kernel paging request at virtual address<br /> | ffffff802a0d8d7171<br /> | Mem abort info:o:<br /> | ESR = 0x9600002121<br /> | EC = 0x25: DABT (current EL), IL = 32 bitsts<br /> | SET = 0, FnV = 0 0<br /> | EA = 0, S1PTW = 0 0<br /> | FSC = 0x21: alignment fault<br /> | Data abort info:o:<br /> | ISV = 0, ISS = 0x0000002121<br /> | CM = 0, WnR = 0 0<br /> | swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000002835200000<br /> | [ffffff802a0d8d71] pgd=180000005fbf9003, p4d=180000005fbf9003,<br /> | pud=180000005fbf9003, pmd=180000005fbe8003, pte=006800002a0d8707<br /> | Internal error: Oops: 96000021 [#1] PREEMPT SMP<br /> | Modules linked in:<br /> | CPU: 2 PID: 45 Comm: kworker/u8:2 Not tainted<br /> | 5.15.78-android13-8-g63561175bbda-dirty #1<br /> | ...<br /> | pc : kcsan_setup_watchpoint+0x26c/0x6bc<br /> | lr : kcsan_setup_watchpoint+0x88/0x6bc<br /> | sp : ffffffc00ab4b7f0<br /> | x29: ffffffc00ab4b800 x28: ffffff80294fe588 x27: 0000000000000001<br /> | x26: 0000000000000019 x25: 0000000000000001 x24: ffffff80294fdb80<br /> | x23: 0000000000000000 x22: ffffffc00a70fb68 x21: ffffff802a0d8d71<br /> | x20: 0000000000000002 x19: 0000000000000000 x18: ffffffc00a9bd060<br /> | x17: 0000000000000001 x16: 0000000000000000 x15: ffffffc00a59f000<br /> | x14: 0000000000000001 x13: 0000000000000000 x12: ffffffc00a70faa0<br /> | x11: 00000000aaaaaaab x10: 0000000000000054 x9 : ffffffc00839adf8<br /> | x8 : ffffffc009b4cf00 x7 : 0000000000000000 x6 : 0000000000000007<br /> | x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffffc00a70fb70<br /> | x2 : 0005ff802a0d8d71 x1 : 0000000000000000 x0 : 0000000000000000<br /> | Call trace:<br /> | kcsan_setup_watchpoint+0x26c/0x6bc<br /> | __tsan_read2+0x1f0/0x234<br /> | inflate_fast+0x498/0x750<br /> | zlib_inflate+0x1304/0x2384<br /> | __gunzip+0x3a0/0x45c<br /> | gunzip+0x20/0x30<br /> | unpack_to_rootfs+0x2a8/0x3fc<br /> | do_populate_rootfs+0xe8/0x11c<br /> | async_run_entry_fn+0x58/0x1bc<br /> | process_one_work+0x3ec/0x738<br /> | worker_thread+0x4c4/0x838<br /> | kthread+0x20c/0x258<br /> | ret_from_fork+0x10/0x20<br /> | Code: b8bfc2a8 2a0803f7 14000007 d503249f (78bfc2a8) )<br /> | ---[ end trace 613a943cb0a572b6 ]-----<br /> <br /> The reason for this is that on certain arm64 configuration since<br /> e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when<br /> CONFIG_LTO=y"), READ_ONCE() may be promoted to a full atomic acquire<br /> instruction which cannot be used on unaligned addresses.<br /> <br /> Fix it by avoiding READ_ONCE() in read_instrumented_memory(), and simply<br /> forcing the compiler to do the required access by casting to the<br /> appropriate volatile type. In terms of generated code this currently<br /> only affects architectures that do not use the default READ_ONCE()<br /> implementation.<br /> <br /> The only downside is that we are not guaranteed atomicity of the access<br /> itself, although on most architectures a plain load up to machine word<br /> size should still be atomic (a fact the default READ_ONCE() still relies<br /> on itself).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Free released resource after coalescing<br /> <br /> release_resource() doesn&amp;#39;t actually free the resource or resource list<br /> entry so free the resource list entry to avoid a leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: ti: pm33xx: Fix refcount leak in am33xx_pm_probe<br /> <br /> wkup_m3_ipc_get() takes refcount, which should be freed by<br /> wkup_m3_ipc_put(). Add missing refcount release in the error paths.