Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm/smu11: Prevent division by zero<br /> <br /> The user can set any speed value.<br /> If speed is greater than UINT_MAX/8, division by zero is possible.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> (cherry picked from commit da7dc714a8f8e1c9fc33c57cd63583779a3bef71)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Prevent division by zero<br /> <br /> The user can set any speed value.<br /> If speed is greater than UINT_MAX/8, division by zero is possible.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Prevent division by zero<br /> <br /> The user can set any speed value.<br /> If speed is greater than UINT_MAX/8, division by zero is possible.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Fix workqueue crash in cma_netevent_work_handler<br /> <br /> struct rdma_cm_id has member "struct work_struct net_work"<br /> that is reused for enqueuing cma_netevent_work_handler()s<br /> onto cma_wq.<br /> <br /> Below crash[1] can occur if more than one call to<br /> cma_netevent_callback() occurs in quick succession,<br /> which further enqueues cma_netevent_work_handler()s for the<br /> same rdma_cm_id, overwriting any previously queued work-item(s)<br /> that was just scheduled to run i.e. there is no guarantee<br /> the queued work item may run between two successive calls<br /> to cma_netevent_callback() and the 2nd INIT_WORK would overwrite<br /> the 1st work item (for the same rdma_cm_id), despite grabbing<br /> id_table_lock during enqueue.<br /> <br /> Also drgn analysis [2] indicates the work item was likely overwritten.<br /> <br /> Fix this by moving the INIT_WORK() to __rdma_create_id(),<br /> so that it doesn&amp;#39;t race with any existing queue_work() or<br /> its worker thread.<br /> <br /> [1] Trimmed crash stack:<br /> =============================================<br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> kworker/u256:6 ... 6.12.0-0...<br /> Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)<br /> RIP: 0010:process_one_work+0xba/0x31a<br /> Call Trace:<br /> worker_thread+0x266/0x3a0<br /> kthread+0xcf/0x100<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> =============================================<br /> <br /> [2] drgn crash analysis:<br /> <br /> &gt;&gt;&gt; trace = prog.crashed_thread().stack_trace()<br /> &gt;&gt;&gt; trace<br /> (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)<br /> (1) __crash_kexec (kernel/crash_core.c:122:4)<br /> (2) panic (kernel/panic.c:399:3)<br /> (3) oops_end (arch/x86/kernel/dumpstack.c:382:3)<br /> ...<br /> (8) process_one_work (kernel/workqueue.c:3168:2)<br /> (9) process_scheduled_works (kernel/workqueue.c:3310:3)<br /> (10) worker_thread (kernel/workqueue.c:3391:4)<br /> (11) kthread (kernel/kthread.c:389:9)<br /> <br /> Line workqueue.c:3168 for this kernel version is in process_one_work():<br /> 3168 strscpy(worker-&gt;desc, pwq-&gt;wq-&gt;name, WORKER_DESC_LEN);<br /> <br /> &gt;&gt;&gt; trace[8]["work"]<br /> *(struct work_struct *)0xffff92577d0a21d8 = {<br /> .data = (atomic_long_t){<br /> .counter = (s64)536870912, &gt;&gt; trace[8]["pwq"]<br /> (struct pool_workqueue *)<br /> <br /> In process_one_work(), pwq is assigned from:<br /> struct pool_workqueue *pwq = get_work_pwq(work);<br /> <br /> and get_work_pwq() is:<br /> static struct pool_workqueue *get_work_pwq(struct work_struct *work)<br /> {<br /> unsigned long data = atomic_long_read(&amp;work-&gt;data);<br /> <br /> if (data &amp; WORK_STRUCT_PWQ)<br /> return work_struct_pwq(data);<br /> else<br /> return NULL;<br /> }<br /> <br /> WORK_STRUCT_PWQ is 0x4:<br /> &gt;&gt;&gt; print(repr(prog[&amp;#39;WORK_STRUCT_PWQ&amp;#39;]))<br /> Object(prog, &amp;#39;enum work_flags&amp;#39;, value=4)<br /> <br /> But work-&gt;data is 536870912 which is 0x20000000.<br /> So, get_work_pwq() returns NULL and we crash in process_one_work():<br /> 3168 strscpy(worker-&gt;desc, pwq-&gt;wq-&gt;name, WORKER_DESC_LEN);<br /> =============================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtiofs: add filesystem context source name check<br /> <br /> In certain scenarios, for example, during fuzz testing, the source<br /> name may be NULL, which could lead to a kernel panic. Therefore, an<br /> extra check for the source name should be added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slab: ensure slab-&gt;obj_exts is clear in a newly allocated slab page<br /> <br /> ktest recently reported crashes while running several buffered io tests<br /> with __alloc_tagging_slab_alloc_hook() at the top of the crash call stack.<br /> The signature indicates an invalid address dereference with low bits of<br /> slab-&gt;obj_exts being set. The bits were outside of the range used by<br /> page_memcg_data_flags and objext_flags and hence were not masked out<br /> by slab_obj_exts() when obtaining the pointer stored in slab-&gt;obj_exts.<br /> The typical crash log looks like this:<br /> <br /> 00510 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> 00510 Mem abort info:<br /> 00510 ESR = 0x0000000096000045<br /> 00510 EC = 0x25: DABT (current EL), IL = 32 bits<br /> 00510 SET = 0, FnV = 0<br /> 00510 EA = 0, S1PTW = 0<br /> 00510 FSC = 0x05: level 1 translation fault<br /> 00510 Data abort info:<br /> 00510 ISV = 0, ISS = 0x00000045, ISS2 = 0x00000000<br /> 00510 CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> 00510 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> 00510 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000104175000<br /> 00510 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> 00510 Internal error: Oops: 0000000096000045 [#1] SMP<br /> 00510 Modules linked in:<br /> 00510 CPU: 10 UID: 0 PID: 7692 Comm: cat Not tainted 6.15.0-rc1-ktest-g189e17946605 #19327 NONE<br /> 00510 Hardware name: linux,dummy-virt (DT)<br /> 00510 pstate: 20001005 (nzCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)<br /> 00510 pc : __alloc_tagging_slab_alloc_hook+0xe0/0x190<br /> 00510 lr : __kmalloc_noprof+0x150/0x310<br /> 00510 sp : ffffff80c87df6c0<br /> 00510 x29: ffffff80c87df6c0 x28: 000000000013d1ff x27: 000000000013d200<br /> 00510 x26: ffffff80c87df9e0 x25: 0000000000000000 x24: 0000000000000001<br /> 00510 x23: ffffffc08041953c x22: 000000000000004c x21: ffffff80c0002180<br /> 00510 x20: fffffffec3120840 x19: ffffff80c4821000 x18: 0000000000000000<br /> 00510 x17: fffffffec3d02f00 x16: fffffffec3d02e00 x15: fffffffec3d00700<br /> 00510 x14: fffffffec3d00600 x13: 0000000000000200 x12: 0000000000000006<br /> 00510 x11: ffffffc080bb86c0 x10: 0000000000000000 x9 : ffffffc080201e58<br /> 00510 x8 : ffffff80c4821060 x7 : 0000000000000000 x6 : 0000000055555556<br /> 00510 x5 : 0000000000000001 x4 : 0000000000000010 x3 : 0000000000000060<br /> 00510 x2 : 0000000000000000 x1 : ffffffc080f50cf8 x0 : ffffff80d801d000<br /> 00510 Call trace:<br /> 00510 __alloc_tagging_slab_alloc_hook+0xe0/0x190 (P)<br /> 00510 __kmalloc_noprof+0x150/0x310<br /> 00510 __bch2_folio_create+0x5c/0xf8<br /> 00510 bch2_folio_create+0x2c/0x40<br /> 00510 bch2_readahead+0xc0/0x460<br /> 00510 read_pages+0x7c/0x230<br /> 00510 page_cache_ra_order+0x244/0x3a8<br /> 00510 page_cache_async_ra+0x124/0x170<br /> 00510 filemap_readahead.isra.0+0x58/0xa0<br /> 00510 filemap_get_pages+0x454/0x7b0<br /> 00510 filemap_read+0xdc/0x418<br /> 00510 bch2_read_iter+0x100/0x1b0<br /> 00510 vfs_read+0x214/0x300<br /> 00510 ksys_read+0x6c/0x108<br /> 00510 __arm64_sys_read+0x20/0x30<br /> 00510 invoke_syscall.constprop.0+0x54/0xe8<br /> 00510 do_el0_svc+0x44/0xc8<br /> 00510 el0_svc+0x18/0x58<br /> 00510 el0t_64_sync_handler+0x104/0x130<br /> 00510 el0t_64_sync+0x154/0x158<br /> 00510 Code: d5384100 f9401c01 b9401aa3 b40002e1 (f8227881)<br /> 00510 ---[ end trace 0000000000000000 ]---<br /> 00510 Kernel panic - not syncing: Oops: Fatal exception<br /> 00510 SMP: stopping secondary CPUs<br /> 00510 Kernel Offset: disabled<br /> 00510 CPU features: 0x0000,000000e0,00000410,8240500b<br /> 00510 Memory Limit: none<br /> <br /> Investigation indicates that these bits are already set when we allocate<br /> slab page and are not zeroed out after allocation. We are not yet sure<br /> why these crashes start happening only recently but regardless of the<br /> reason, not initializing a field that gets used later is wrong. Fix it<br /> by initializing slab-&gt;obj_exts during slab page allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: fix firmware memory leaks<br /> <br /> Free the memory used to hold the results of firmware image processing<br /> when the module is unloaded.<br /> <br /> Fix the related issue of the same memory being leaked if processing<br /> of the firmware image fails during module load.<br /> <br /> Ensure all firmware GEM objects are destroyed if firmware image<br /> processing fails.<br /> <br /> Fixes memory leaks on powervr module unload detected by Kmemleak:<br /> <br /> unreferenced object 0xffff000042e20000 (size 94208):<br /> comm "modprobe", pid 470, jiffies 4295277154<br /> hex dump (first 32 bytes):<br /> 02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: prime: fix ttm_bo_delayed_delete oops<br /> <br /> Fix an oops in ttm_bo_delayed_delete which results from dererencing a<br /> dangling pointer:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP<br /> CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216<br /> Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024<br /> Workqueue: ttm ttm_bo_delayed_delete [ttm]<br /> RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290<br /> Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b<br /> RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b<br /> R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc<br /> FS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x26<br /> ? die_addr+0x3d/0x70<br /> ? exc_general_protection+0x159/0x460<br /> ? asm_exc_general_protection+0x27/0x30<br /> ? dma_resv_iter_first_unlocked+0x55/0x290<br /> dma_resv_wait_timeout+0x56/0x100<br /> ttm_bo_delayed_delete+0x69/0xb0 [ttm]<br /> process_one_work+0x217/0x5c0<br /> worker_thread+0x1c8/0x3d0<br /> ? apply_wqattrs_cleanup.part.0+0xc0/0xc0<br /> kthread+0x10b/0x240<br /> ? kthreads_online_cpu+0x140/0x140<br /> ret_from_fork+0x40/0x70<br /> ? kthreads_online_cpu+0x140/0x140<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> <br /> The cause of this is:<br /> <br /> - drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the<br /> reference to the shared dma_buf. The reference count is 0, so the<br /> dma_buf is destroyed, which in turn decrements the corresponding<br /> amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed -<br /> calling drm_gem_object_release then dma_resv_fini (which destroys the<br /> reservation object), then finally freeing the amdgpu_bo.<br /> <br /> - nouveau_bo obj-&gt;bo.base.resv is now a dangling pointer to the memory<br /> formerly allocated to the amdgpu_bo.<br /> <br /> - nouveau_gem_object_del calls ttm_bo_put(&amp;nvbo-&gt;bo) which calls<br /> ttm_bo_release, which schedules ttm_bo_delayed_delete.<br /> <br /> - ttm_bo_delayed_delete runs and dereferences the dangling resv pointer,<br /> resulting in a general protection fault.<br /> <br /> Fix this by moving the drm_prime_gem_destroy call from<br /> nouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will<br /> be run after ttm_bo_delayed_delete.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Prevent division by zero<br /> <br /> The user can set any speed value.<br /> If speed is greater than UINT_MAX/8, division by zero is possible.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Prevent division by zero<br /> <br /> The user can set any speed value.<br /> If speed is greater than UINT_MAX/8, division by zero is possible.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Prevent division by zero<br /> <br /> The user can set any speed value.<br /> If speed is greater than UINT_MAX/8, division by zero is possible.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vma: add give_up_on_oom option on modify/merge, use in uffd release<br /> <br /> Currently, if a VMA merge fails due to an OOM condition arising on commit<br /> merge or a failure to duplicate anon_vma&amp;#39;s, we report this so the caller<br /> can handle it.<br /> <br /> However there are cases where the caller is only ostensibly trying a<br /> merge, and doesn&amp;#39;t mind if it fails due to this condition.<br /> <br /> Since we do not want to introduce an implicit assumption that we only<br /> actually modify VMAs after OOM conditions might arise, add a &amp;#39;give up on<br /> oom&amp;#39; option and make an explicit contract that, should this flag be set, we<br /> absolutely will not modify any VMAs should OOM arise and just bail out.<br /> <br /> Since it&amp;#39;d be very unusual for a user to try to vma_modify() with this flag<br /> set but be specifying a range within a VMA which ends up being split (which<br /> can fail due to rlimit issues, not only OOM), we add a debug warning for<br /> this condition.<br /> <br /> The motivating reason for this is uffd release - syzkaller (and Pedro<br /> Falcato&amp;#39;s VERY astute analysis) found a way in which an injected fault on<br /> allocation, triggering an OOM condition on commit merge, would result in<br /> uffd code becoming confused and treating an error value as if it were a VMA<br /> pointer.<br /> <br /> To avoid this, we make use of this new VMG flag to ensure that this never<br /> occurs, utilising the fact that, should we be clearing entire VMAs, we do<br /> not wish an OOM event to be reported to us.<br /> <br /> Many thanks to Pedro Falcato for his excellent analysis and Jann Horn for<br /> his insightful and intelligent analysis of the situation, both of whom were<br /> instrumental in this fix.