Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix page frag corruption on page fault<br /> <br /> Steffen reported a TCP stream corruption for HTTP requests<br /> served by the apache web-server using a cifs mount-point<br /> and memory mapping the relevant file.<br /> <br /> The root cause is quite similar to the one addressed by<br /> commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from<br /> memory reclaim"). Here the nested access to the task page frag<br /> is caused by a page fault on the (mmapped) user-space memory<br /> buffer coming from the cifs file.<br /> <br /> The page fault handler performs an smb transaction on a different<br /> socket, inside the same process context. Since sk-&gt;sk_allaction<br /> for such socket does not prevent the usage for the task_frag,<br /> the nested allocation modify "under the hood" the page frag<br /> in use by the outer sendmsg call, corrupting the stream.<br /> <br /> The overall relevant stack trace looks like the following:<br /> <br /> httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked:<br /> ffffffff91461d91 tcp_sendmsg_locked+0x1<br /> ffffffff91462b57 tcp_sendmsg+0x27<br /> ffffffff9139814e sock_sendmsg+0x3e<br /> ffffffffc06dfe1d smb_send_kvec+0x28<br /> [...]<br /> ffffffffc06cfaf8 cifs_readpages+0x213<br /> ffffffff90e83c4b read_pages+0x6b<br /> ffffffff90e83f31 __do_page_cache_readahead+0x1c1<br /> ffffffff90e79e98 filemap_fault+0x788<br /> ffffffff90eb0458 __do_fault+0x38<br /> ffffffff90eb5280 do_fault+0x1a0<br /> ffffffff90eb7c84 __handle_mm_fault+0x4d4<br /> ffffffff90eb8093 handle_mm_fault+0xc3<br /> ffffffff90c74f6d __do_page_fault+0x1ed<br /> ffffffff90c75277 do_page_fault+0x37<br /> ffffffff9160111e page_fault+0x1e<br /> ffffffff9109e7b5 copyin+0x25<br /> ffffffff9109eb40 _copy_from_iter_full+0xe0<br /> ffffffff91462370 tcp_sendmsg_locked+0x5e0<br /> ffffffff91462370 tcp_sendmsg_locked+0x5e0<br /> ffffffff91462b57 tcp_sendmsg+0x27<br /> ffffffff9139815c sock_sendmsg+0x4c<br /> ffffffff913981f7 sock_write_iter+0x97<br /> ffffffff90f2cc56 do_iter_readv_writev+0x156<br /> ffffffff90f2dff0 do_iter_write+0x80<br /> ffffffff90f2e1c3 vfs_writev+0xa3<br /> ffffffff90f2e27c do_writev+0x5c<br /> ffffffff90c042bb do_syscall_64+0x5b<br /> ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65<br /> <br /> The cifs filesystem rightfully sets sk_allocations to GFP_NOFS,<br /> we can avoid the nesting using the sk page frag for allocation<br /> lacking the __GFP_FS flag. Do not define an additional mm-helper<br /> for that, as this is strictly tied to the sk page frag usage.<br /> <br /> v1 -&gt; v2:<br /> - use a stricted sk_page_frag() check instead of reordering the<br /> code (Eric)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a6xx: Allocate enough space for GMU registers<br /> <br /> In commit 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for<br /> A650") we changed a6xx_get_gmu_registers() to read 3 sets of<br /> registers. Unfortunately, we didn&amp;#39;t change the memory allocation for<br /> the array. That leads to a KASAN warning (this was on the chromeos-5.4<br /> kernel, which has the problematic commit backported to it):<br /> <br /> BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430<br /> Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209<br /> CPU: 5 PID: 209 Comm: A618-worker Tainted: G W 5.4.156-lockdep #22<br /> Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x248<br /> show_stack+0x20/0x2c<br /> dump_stack+0x128/0x1ec<br /> print_address_description+0x88/0x4a0<br /> __kasan_report+0xfc/0x120<br /> kasan_report+0x10/0x18<br /> __asan_report_store8_noabort+0x1c/0x24<br /> _a6xx_get_gmu_registers+0x144/0x430<br /> a6xx_gpu_state_get+0x330/0x25d4<br /> msm_gpu_crashstate_capture+0xa0/0x84c<br /> recover_worker+0x328/0x838<br /> kthread_worker_fn+0x32c/0x574<br /> kthread+0x2dc/0x39c<br /> ret_from_fork+0x10/0x18<br /> <br /> Allocated by task 209:<br /> __kasan_kmalloc+0xfc/0x1c4<br /> kasan_kmalloc+0xc/0x14<br /> kmem_cache_alloc_trace+0x1f0/0x2a0<br /> a6xx_gpu_state_get+0x164/0x25d4<br /> msm_gpu_crashstate_capture+0xa0/0x84c<br /> recover_worker+0x328/0x838<br /> kthread_worker_fn+0x32c/0x574<br /> kthread+0x2dc/0x39c<br /> ret_from_fork+0x10/0x18

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix wrong list_del in smc_lgr_cleanup_early<br /> <br /> smc_lgr_cleanup_early() meant to delete the link<br /> group from the link group list, but it deleted<br /> the list head by mistake.<br /> <br /> This may cause memory corruption since we didn&amp;#39;t<br /> remove the real link group from the list and later<br /> memseted the link group structure.<br /> We got a list corruption panic when testing:<br /> <br /> [  231.277259] list_del corruption. prev-&gt;next should be ffff8881398a8000, but was 0000000000000000<br /> [  231.278222] ------------[ cut here ]------------<br /> [  231.278726] kernel BUG at lib/list_debug.c:53!<br /> [  231.279326] invalid opcode: 0000 [#1] SMP NOPTI<br /> [  231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435<br /> [  231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014<br /> [  231.281248] Workqueue: events smc_link_down_work<br /> [  231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90<br /> [  231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c<br /> 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <br /> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc<br /> [  231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292<br /> [  231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000<br /> [  231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040<br /> [  231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001<br /> [  231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001<br /> [  231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003<br /> [  231.288337] FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000<br /> [  231.289160] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [  231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0<br /> [  231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [  231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [  231.291940] Call Trace:<br /> [  231.292211]  smc_lgr_terminate_sched+0x53/0xa0<br /> [  231.292677]  smc_switch_conns+0x75/0x6b0<br /> [  231.293085]  ? update_load_avg+0x1a6/0x590<br /> [  231.293517]  ? ttwu_do_wakeup+0x17/0x150<br /> [  231.293907]  ? update_load_avg+0x1a6/0x590<br /> [  231.294317]  ? newidle_balance+0xca/0x3d0<br /> [  231.294716]  smcr_link_down+0x50/0x1a0<br /> [  231.295090]  ? __wake_up_common_lock+0x77/0x90<br /> [  231.295534]  smc_link_down_work+0x46/0x60<br /> [  231.295933]  process_one_work+0x18b/0x350

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Fix a memleak bug in rvu_mbox_init()<br /> <br /> In rvu_mbox_init(), mbox_regions is not freed or passed out<br /> under the switch-default region, which could lead to a memory leak.<br /> <br /> Fix this bug by changing &amp;#39;return err&amp;#39; to &amp;#39;goto free_regions&amp;#39;.<br /> <br /> This bug was found by a static analyzer. The analysis employs<br /> differential checking to identify inconsistent security operations<br /> (e.g., checks or kfrees) between two code paths and confirms that the<br /> inconsistent operations are not recovered in the current function or<br /> the callers, so they constitute bugs.<br /> <br /> Note that, as a bug found by static analysis, it can be a false<br /> positive or hard to trigger. Multiple researchers have cross-reviewed<br /> the bug.<br /> <br /> Builds with CONFIG_OCTEONTX2_AF=y show no new warnings,<br /> and our static analyzer no longer warns about this code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer()<br /> <br /> Need to call rxrpc_put_local() for peer candidate before kfree() as it<br /> holds a ref to rxrpc_local.<br /> <br /> [DH: v2: Changed to abstract the peer freeing code out into a function]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix rxrpc_peer leak in rxrpc_look_up_bundle()<br /> <br /> Need to call rxrpc_put_peer() for bundle candidate before kfree() as it<br /> holds a ref to rxrpc_peer.<br /> <br /> [DH: v2: Changed to abstract out the bundle freeing code into a function]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix wait_fence submitqueue leak<br /> <br /> We weren&amp;#39;t dropping the submitqueue reference in all paths. In<br /> particular, when the fence has already been signalled. Split out<br /> a helper to simplify handling this in the various different return<br /> paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP<br /> <br /> In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object<br /> function") we switched to a new/cleaner method of doing things. That&amp;#39;s<br /> good, but we missed a little bit.<br /> <br /> Before that commit, we used to _first_ run through the<br /> drm_gem_mmap_obj() case where `obj-&gt;funcs-&gt;mmap()` was NULL. That meant<br /> that we ran:<br /> <br /> vma-&gt;vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;<br /> vma-&gt;vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma-&gt;vm_flags));<br /> vma-&gt;vm_page_prot = pgprot_decrypted(vma-&gt;vm_page_prot);<br /> <br /> ...and _then_ we modified those mappings with our own. Now that<br /> `obj-&gt;funcs-&gt;mmap()` is no longer NULL we don&amp;#39;t run the default<br /> code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP<br /> was important because we&amp;#39;re now getting crashes on Chromebooks that<br /> use ARC++ while logging out. Specifically a crash that looks like this<br /> (this is on a 5.10 kernel w/ relevant backports but also seen on a<br /> 5.15 kernel):<br /> <br /> Unable to handle kernel paging request at virtual address ffffffc008000000<br /> Mem abort info:<br /> ESR = 0x96000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000006<br /> CM = 0, WnR = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008293d000<br /> [ffffffc008000000] pgd=00000001002b3003, p4d=00000001002b3003,<br /> pud=00000001002b3003, pmd=0000000000000000<br /> Internal error: Oops: 96000006 [#1] PREEMPT SMP<br /> [...]<br /> CPU: 7 PID: 15734 Comm: crash_dump64 Tainted: G W 5.10.67 #1 [...]<br /> Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT)<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)<br /> pc : __arch_copy_to_user+0xc0/0x30c<br /> lr : copyout+0xac/0x14c<br /> [...]<br /> Call trace:<br /> __arch_copy_to_user+0xc0/0x30c<br /> copy_page_to_iter+0x1a0/0x294<br /> process_vm_rw_core+0x240/0x408<br /> process_vm_rw+0x110/0x16c<br /> __arm64_sys_process_vm_readv+0x30/0x3c<br /> el0_svc_common+0xf8/0x250<br /> do_el0_svc+0x30/0x80<br /> el0_svc+0x10/0x1c<br /> el0_sync_handler+0x78/0x108<br /> el0_sync+0x184/0x1c0<br /> Code: f8408423 f80008c3 910020c6 36100082 (b8404423)<br /> <br /> Let&amp;#39;s add the two flags back in.<br /> <br /> While we&amp;#39;re at it, the fact that we aren&amp;#39;t running the default means<br /> that we _don&amp;#39;t_ need to clear out VM_PFNMAP, so remove that and save<br /> an instruction.<br /> <br /> NOTE: it was confirmed that VM_IO was the important flag to fix the<br /> problem I was seeing, but adding back VM_DONTDUMP seems like a sane<br /> thing to do so I&amp;#39;m doing that too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/devfreq: Fix OPP refcnt leak

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: kms: Clear the HVS FIFO commit pointer once done<br /> <br /> Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a<br /> commit") introduced a wait on the previous commit done on a given HVS<br /> FIFO.<br /> <br /> However, we never cleared that pointer once done. Since<br /> drm_crtc_commit_put can free the drm_crtc_commit structure directly if<br /> we were the last user, this means that it can lead to a use-after free<br /> if we were to duplicate the state, and that stale pointer would even be<br /> copied to the new state.<br /> <br /> Set the pointer to NULL once we&amp;#39;re done with the wait so that we don&amp;#39;t<br /> carry over a pointer to a free&amp;#39;d structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: kms: Add missing drm_crtc_commit_put<br /> <br /> Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a<br /> commit") introduced a global state for the HVS, with each FIFO storing<br /> the current CRTC commit so that we can properly synchronize commits.<br /> <br /> However, the refcounting was off and we thus ended up leaking the<br /> drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to<br /> prevent the leakage.