No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: iris: Fix memory leak by freeing untracked persist buffer\n\nOne internal buffer which is allocated only once per session was not\nbeing freed during session close because it was not being tracked as\npart of internal buffer list which resulted in a memory leak.\n\nAdd the necessary logic to explicitly free the untracked internal buffer\nduring session close to ensure all allocated memory is released\nproperly.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: stm32-csi: Fix dereference before NULL check\n\nIn 'stm32_csi_start', 'csidev->s_subdev' is dereferenced directly while\nassigning a value to the 'src_pad'. However the same value is being\nchecked against NULL at a later point of time indicating that there\nare chances that the value can be NULL.\n\nMove the dereference after the NULL check.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix warning in smc_rx_splice() when calling get_page()\n\nsmc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are\nlater passed to get_page() in smc_rx_splice(). Since kmalloc memory is\nnot page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents\nholding a refcount on the buffer. This can lead to use-after-free if\nthe memory is released before splice_to_pipe() completes.\n\nUse folio_alloc() instead, ensuring DMBs are page-backed and safe for\nget_page().\n\nWARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc]\nCPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE\nHardware name: IBM 3931 A01 704 (z/VM 7.4.0)\nKrnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc])\n R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3\nKrnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005\n 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000\n 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000\n 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8\nKrnl Code: 0007931610326960: af000000 mc 0,0\n 0007931610326964: a7f4ff43 brc 15,00079316103267ea\n #0007931610326968: af000000 mc 0,0\n >000793161032696c: a7f4ff3f brc 15,00079316103267ea\n 0007931610326970: e320f1000004 lg %r2,256(%r15)\n 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560\n 000793161032697c: a7f4fbb5 brc 15,00079316103260e6\n 0007931610326980: b904002b lgr %r2,%r11\nCall Trace:\n smc_rx_splice+0xafc/0xe20 [smc]\n smc_rx_splice+0x756/0xe20 [smc])\n smc_rx_recvmsg+0xa74/0xe00 [smc]\n smc_splice_read+0x1ce/0x3b0 [smc]\n sock_splice_read+0xa2/0xf0\n do_splice_read+0x198/0x240\n splice_file_to_pipe+0x7e/0x110\n do_splice+0x59e/0xde0\n __do_splice+0x11a/0x2d0\n __s390x_sys_splice+0x140/0x1f0\n __do_syscall+0x122/0x280\n system_call+0x6e/0x90\nLast Breaking-Event-Address:\nsmc_rx_splice+0x960/0xe20 [smc]\n---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc/task_mmu: check p->vec_buf for NULL\n\nWhen the PAGEMAP_SCAN ioctl is invoked with vec_len = 0 reaches\npagemap_scan_backout_range(), kernel panics with null-ptr-deref:\n\n[ 44.936808] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 44.937797] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n[ 44.938391] CPU: 1 UID: 0 PID: 2480 Comm: reproducer Not tainted 6.17.0-rc6 #22 PREEMPT(none)\n[ 44.939062] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 44.939935] RIP: 0010:pagemap_scan_thp_entry.isra.0+0x741/0xa80\n\n\n\n[ 44.946828] Call Trace:\n[ 44.947030] \n[ 44.949219] pagemap_scan_pmd_entry+0xec/0xfa0\n[ 44.952593] walk_pmd_range.isra.0+0x302/0x910\n[ 44.954069] walk_pud_range.isra.0+0x419/0x790\n[ 44.954427] walk_p4d_range+0x41e/0x620\n[ 44.954743] walk_pgd_range+0x31e/0x630\n[ 44.955057] __walk_page_range+0x160/0x670\n[ 44.956883] walk_page_range_mm+0x408/0x980\n[ 44.958677] walk_page_range+0x66/0x90\n[ 44.958984] do_pagemap_scan+0x28d/0x9c0\n[ 44.961833] do_pagemap_cmd+0x59/0x80\n[ 44.962484] __x64_sys_ioctl+0x18d/0x210\n[ 44.962804] do_syscall_64+0x5b/0x290\n[ 44.963111] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nvec_len = 0 in pagemap_scan_init_bounce_buffer() means no buffers are\nallocated and p->vec_buf remains set to NULL.\n\nThis breaks an assumption made later in pagemap_scan_backout_range(), that\npage_region is always allocated for p->vec_buf_index.\n\nFix it by explicitly checking p->vec_buf for NULL before dereferencing.\n\nOther sites that might run into same deref-issue are already (directly or\ntransitively) protected by checking p->vec_buf.\n\nNote:\nFrom PAGEMAP_SCAN man page, it seems vec_len = 0 is valid when no output\nis requested and it's only the side effects caller is interested in,\nhence it passes check in pagemap_scan_get_args().\n\nThis issue was found by syzkaller.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: fix reference leak\n\nCommit 20d72b00ca81 ("netfs: Fix the request's work item to not\nrequire a ref") modified netfs_alloc_request() to initialize the\nreference counter to 2 instead of 1. The rationale was that the\nrequet's "work" would release the second reference after completion\n(via netfs_{read,write}_collection_worker()). That works most of the\ntime if all goes well.\n\nHowever, it leaks this additional reference if the request is released\nbefore the I/O operation has been submitted: the error code path only\ndecrements the reference counter once and the work item will never be\nqueued because there will never be a completion.\n\nThis has caused outages of our whole server cluster today because\ntasks were blocked in netfs_wait_for_outstanding_io(), leading to\ndeadlocks in Ceph (another bug that I will address soon in another\npatch). This was caused by a netfs_pgpriv2_begin_copy_to_cache() call\nwhich failed in fscache_begin_write_operation(). The leaked\nnetfs_io_request was never completed, leaving `netfs_inode.io_count`\nwith a positive value forever.\n\nAll of this is super-fragile code. Finding out which code paths will\nlead to an eventual completion and which do not is hard to see:\n\n- Some functions like netfs_create_write_req() allocate a request, but\n will never submit any I/O.\n\n- netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read()\n and then netfs_put_request(); however, netfs_unbuffered_read() can\n also fail early before submitting the I/O request, therefore another\n netfs_put_request() call must be added there.\n\nA rule of thumb is that functions that return a `netfs_io_request` do\nnot submit I/O, and all of their callers must be checked.\n\nFor my taste, the whole netfs code needs an overhaul to make reference\ncounting easier to understand and less fragile & obscure. But to fix\nthis bug here and now and produce a patch that is adequate for a\nstable backport, I tried a minimal approach that quickly frees the\nrequest object upon early failure.\n\nI decided against adding a second netfs_put_request() each time\nbecause that would cause code duplication which obscures the code\nfurther. Instead, I added the function netfs_put_failed_request()\nwhich frees such a failed request synchronously under the assumption\nthat the reference count is exactly 2 (as initially set by\nnetfs_alloc_request() and never touched), verified by a\nWARN_ON_ONCE(). It then deinitializes the request object (without\ngoing through the "cleanup_work" indirection) and frees the allocation\n(with RCU protection to protect against concurrent access by\nnetfs_requests_seq_start()).\n\nAll code paths that fail early have been changed to call\nnetfs_put_failed_request() instead of netfs_put_request().\nAdditionally, I have added a netfs_put_request() call to\nnetfs_unbuffered_read() as explained above because the\nnetfs_put_failed_request() approach does not work there.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:ice: fix memleak in ice_init_tx_topology()Fix leak of the FW blob (DDP pkg).Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoidcopying whole FW blob. Copy just the topology section, and only whenneeded. Reuse the buffer allocated for the read of the current topology.This was found by kmemleak, with the following trace for each PF:[] kmemdup_noprof+0x1d/0x50[] ice_init_ddp_config+0x100/0x220 [ice][] ice_init_dev+0x6f/0x200 [ice][] ice_init+0x29/0x560 [ice][] ice_probe+0x21d/0x310 [ice]Constify ice_cfg_tx_topo() @buf parameter.This cascades further down to few more functions.

In the Linux kernel, the following vulnerability has been resolved:\n\nkmsan: fix out-of-bounds access to shadow memory\n\nRunning sha224_kunit on a KMSAN-enabled kernel results in a crash in\nkmsan_internal_set_shadow_origin():\n\n BUG: unable to handle page fault for address: ffffbc3840291000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 1810067 P4D 1810067 PUD 192d067 PMD 3c17067 PTE 0\n Oops: 0000 [#1] SMP NOPTI\n CPU: 0 UID: 0 PID: 81 Comm: kunit_try_catch Tainted: G N 6.17.0-rc3 #10 PREEMPT(voluntary)\n Tainted: [N]=TEST\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n RIP: 0010:kmsan_internal_set_shadow_origin+0x91/0x100\n [...]\n Call Trace:\n \n __msan_memset+0xee/0x1a0\n sha224_final+0x9e/0x350\n test_hash_buffer_overruns+0x46f/0x5f0\n ? kmsan_get_shadow_origin_ptr+0x46/0xa0\n ? __pfx_test_hash_buffer_overruns+0x10/0x10\n kunit_try_run_case+0x198/0xa00\n\nThis occurs when memset() is called on a buffer that is not 4-byte aligned\nand extends to the end of a guard page, i.e. the next page is unmapped.\n\nThe bug is that the loop at the end of kmsan_internal_set_shadow_origin()\naccesses the wrong shadow memory bytes when the address is not 4-byte\naligned. Since each 4 bytes are associated with an origin, it rounds the\naddress and size so that it can access all the origins that contain the\nbuffer. However, when it checks the corresponding shadow bytes for a\nparticular origin, it incorrectly uses the original unrounded shadow\naddress. This results in reads from shadow memory beyond the end of the\nbuffer's shadow memory, which crashes when that memory is not mapped.\n\nTo fix this, correctly align the shadow address before accessing the 4\nshadow bytes corresponding to each origin.

No description is available for this CVE.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:phy: qcom: qmp-usbc: fix NULL-deref on runtime suspendCommit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation")removed most users of the platform device driver data from theqcom-qmp-usb driver, but mistakenly also removed the initialisationdespite the data still being used in the runtime PM callbacks. This bugwas later reproduced when the driver was copied to create the qmp-usbcdriver.Restore the driver data initialisation at probe to avoid a NULL-pointerdereference on runtime suspend.Apparently no one uses runtime PM, which currently needs to be enabledmanually through sysfs, with these drivers.

In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan()KASAN reported following issue:BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt]Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387Tainted: [U]=USERWorkqueue: thunderbolt0 tb_handle_hotplug [thunderbolt]Call Trace:dump_stack_lvl+0x6c/0x90print_report+0xd1/0x630kasan_report+0xdb/0x110__asan_report_load4_noabort+0x14/0x20tb_retimer_scan+0xffe/0x1550 [thunderbolt]tb_scan_port+0xa6f/0x2060 [thunderbolt]tb_handle_hotplug+0x17b1/0x3080 [thunderbolt]process_one_work+0x626/0x1100worker_thread+0x6c8/0xfa0kthread+0x2c8/0x3a0ret_from_fork+0x3a/0x80ret_from_fork_asm+0x1a/0x30This happens because the loop variable still gets incremented by one somax becomes 3 instead of 2, and this makes the second loop read past thethe array declared on the stack.Fix this by assigning to max directly in the loop body.

In the Linux kernel, the following vulnerability has been resolved:fork: do not invoke uffd on fork if error occursPatch series "fork: do not expose incomplete mm on fork".During fork we may place the virtual memory address space into aninconsistent state before the fork operation is complete.In addition, we may encounter an error during the fork operation thatindicates that the virtual memory address space is invalidated.As a result, we should not be exposing it in any way to external machinerythat might interact with the mm or VMAs, machinery that is not designed todeal with incomplete state.We specifically update the fork logic to defer khugepaged and ksm to theend of the operation and only to be invoked if no error arose, anddisallow uffd from observing fork events should an error have occurred.This patch (of 2):Currently on fork we expose the virtual address space of a process touserland unconditionally if uffd is registered in VMAs, regardless ofwhether an error arose in the fork.This is performed in dup_userfaultfd_complete() which is invokedunconditionally, and performs two duties - invoking registered handlersfor the UFFD_EVENT_FORK event via dup_fctx(), and clearing downuserfaultfd_fork_ctx objects established in dup_userfaultfd().This is problematic, because the virtual address space may not yet becorrectly initialised if an error arose.The change in commit d24062914837 ("fork: use __mt_dup() to duplicatemaple tree in dup_mmap()") makes this more pertinent as we may be in astate where entries in the maple tree are not yet consistent.We address this by, on fork error, ensuring that we roll back state thatwe would otherwise expect to clean up through the event being handled byuserland and perform the memory freeing duty otherwise performed bydup_userfaultfd_complete().We do this by implementing a new function, dup_userfaultfd_fail(), whichperforms the same loop, only decrementing reference counts.Note that we perform mmgrab() on the parent and child mm's, howeveruserfaultfd_ctx_put() will mmdrop() this once the reference count drops tozero, so we will avoid memory leaks correctly here.

In the Linux kernel, the following vulnerability has been resolved:drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()modprobe drm_connector_test and then rmmod drm_connector_test,the following memory leak occurs.The `mode` allocated in drm_mode_duplicate() called bydrm_display_mode_from_cea_vic() is not freed, which cause the memory leak:unreferenced object 0xffffff80cb0ee400 (size 128):comm "kunit_try_catch", pid 1948, jiffies 4294950339hex dump (first 32 bytes):14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8.3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e...........backtrace (crc 90e9585c):[<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40[<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4[<00000000c2062161>] drm_mode_duplicate+0x44/0x19c[<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98[<00000000d8f2c8b4>] 0xffffffdc982a4868[<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac[<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec[<000000006ea56ca0>] kthread+0x2e8/0x374[<000000000676063f>] ret_from_fork+0x10/0x20......Free `mode` by using drm_kunit_display_mode_from_cea_vic()to fix it.

In the Linux kernel, the following vulnerability has been resolved:drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()modprobe drm_hdmi_state_helper_test and then rmmod it, the followingmemory leak occurs.The `mode` allocated in drm_mode_duplicate() called bydrm_display_mode_from_cea_vic() is not freed, which cause the memory leak:unreferenced object 0xffffff80ccd18100 (size 128):comm "kunit_try_catch", pid 1851, jiffies 4295059695hex dump (first 32 bytes):57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ .....ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................backtrace (crc c2f1aa95):[<000000000f10b11b>] kmemleak_alloc+0x34/0x40[<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4[<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c[<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98[<0000000019daaacf>] 0xffffffedc11ae69c[<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac[<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec[<000000000a0b2e9e>] kthread+0x2e8/0x374[<00000000bd668858>] ret_from_fork+0x10/0x20......Free `mode` by using drm_kunit_display_mode_from_cea_vic()to fix it.

In the Linux kernel, the following vulnerability has been resolved:lib: alloc_tag_module_unload must wait for pending kfree_rcu callsBen Greear reports following splat:------------[ cut here ]------------net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unloadWARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat...Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0codetag_unload_module+0x19b/0x2a0? codetag_load_module+0x80/0x80nf_nat module exit calls kfree_rcu on those addresses, but the freeoperation is likely still pending by the time alloc_tag checks for leaks.Wait for outstanding kfree_rcu operations to complete before checkingresolves this warning.Reproducer:unshare -n iptables-nft -t nat -A PREROUTING -p tcpgrep nf_nat /proc/allocinfo # will list 4 allocationsrmmod nft_chain_natrmmod nf_nat # will WARN.[akpm@linux-foundation.org: add comment]

In the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid's fd,and get the clk->rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid's fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the "ts" is not changedafter that.[pabeni@redhat.com: fixed commit message typo]

In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Fix reader locking when changing the sub buffer orderThe function ring_buffer_subbuf_order_set() updates eachring_buffer_per_cpu and installs new sub buffers that match the requestedpage order. This operation may be invoked concurrently with readers thatrely on some of the modified data, such as the head bit (RB_PAGE_HEAD), orthe ring_buffer_per_cpu.pages and reader_page pointers. However, noexclusive access is acquired by ring_buffer_subbuf_order_set(). Modifyingthe mentioned data while a reader also operates on them can then result inincorrect memory access and various crashes.Fix the problem by taking the reader_lock when updating a specificring_buffer_per_cpu in ring_buffer_subbuf_order_set().

In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: fix memory corruption during fq dma initThe loop responsible for allocating up to MTK_FQ_DMA_LENGTH buffers mustonly touch as many descriptors, otherwise it ends up corrupting unrelatedmemory. Fix the loop iteration count accordingly.

In the Linux kernel, the following vulnerability has been resolved:fs: don't try and remove empty rbtree nodeWhen copying a namespace we won't have added the new copy into thenamespace rbtree until after the copy succeeded. Calling free_mnt_ns()will try to remove the copy from the rbtree which is invalid. Simplyfree the namespace skeleton directly.

In the Linux kernel, the following vulnerability has been resolved:cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()Use raw_smp_processor_id() instead of plain smp_processor_id() indo_service_request(), otherwise we may get some errors with the driverenabled:BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]

In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix a UBSAN warning in DML2.1When programming phantom pipe, since cursor_width is explicity set to 0,this causes calculation logic to trigger overflow for an unsigned inttriggering the kernel's UBSAN check as below:[ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34[ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int'[ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu[ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024[ 40.962856] Call Trace:[ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70[ 40.962870] dump_stack+0x10/0x20[ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360[ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu][ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu][ 40.963327] ? srso_alias_return_thunk+0x5/0x7f[ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu][ 40.963534] ? srso_alias_return_thunk+0x5/0x7f[ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu][ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu][ 40.963906] ? srso_alias_return_thunk+0x5/0x7f[ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu][ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu][ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu][ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu][ 40.964587] dml21_validate+0x274/0x770 [amdgpu][ 40.964761] ? srso_alias_return_thunk+0x5/0x7f[ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu][ 40.964942] dml2_validate+0x504/0x750 [amdgpu][ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu][ 40.965291] ? srso_alias_return_thunk+0x5/0x7f[ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu][ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu][ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu][ 40.965845] ? srso_alias_return_thunk+0x5/0x7f[ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu]Fix this by adding a guard for checking cursor width before triggeringthe size calculation.

In the Linux kernel, the following vulnerability has been resolved:remoteproc: k3-r5: Fix error handling when power-up failedBy simply bailing out, the driver was violating its rule and internalassumptions that either both or no rproc should be initialized. E.g.,this could cause the first core to be available but not the second one,leading to crashes on its shutdown later on while trying to dereferencethat second instance.

In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix race when converting group handle to group objectXArray provides it's own internal lock which protects the internal arraywhen entries are being simultaneously added and removed. However thereis still a race between retrieving the pointer from the XArray andincrementing the reference count.To avoid this race simply hold the internal XArray lock whenincrementing the reference count, this ensures there cannot be a racingcall to xa_erase().

In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()The group variable can't be used to retrieve ptdev in our second loop,because it points to the previously iterated list_head, not a validgroup. Get the ptdev object from the scheduler instead.

In the Linux kernel, the following vulnerability has been resolved:btrfs: reject ro->rw reconfiguration if there are hard ro requirements[BUG]Syzbot reports the following crash:BTRFS info (device loop0 state MCS): disabling free space treeBTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1)BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [inline]RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041Call Trace:btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012btrfs_remount_rw fs/btrfs/super.c:1309 [inline]btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [inline]btrfs_get_tree_subvol fs/btrfs/super.c:2079 [inline]btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115vfs_get_tree+0x90/0x2b0 fs/super.c:1800do_new_mount+0x2be/0xb40 fs/namespace.c:3472do_mount fs/namespace.c:3812 [inline]__do_sys_mount fs/namespace.c:4020 [inline]__se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7f[CAUSE]To support mounting different subvolume with different RO/RW flags forthe new mount APIs, btrfs introduced two workaround to support this feature:- Skip mount option/feature checks if we are mounting a differentsubvolume- Reconfigure the fs to RW if the initial mount is ROCombining these two, we can have the following sequence:- Mount the fs ro,rescue=all,clear_cache,space_cache=v1rescue=all will mark the fs as hard read-only, so no v2 cache clearingwill happen.- Mount a subvolume rw of the same fs.We go into btrfs_get_tree_subvol(), but fc_mount() returns EBUSYbecause our new fc is RW, different from the original fs.Now we enter btrfs_reconfigure_for_mount(), which switches the RO flagfirst so that we can grab the existing fs_info.Then we reconfigure the fs to RW.- During reconfiguration, option/features check is skippedThis means we will restart the v2 cache clearing, and convert back tov1 cache.This will trigger fs writes, and since the original fs has "rescue=all"option, it skips the csum tree read.And eventually causing NULL pointer dereference in super blockwriteback.[FIX]For reconfiguration caused by different subvolume RO/RW flags, ensure wealways run btrfs_check_options() to ensure we have proper hard ROrequirements met.In fact the function btrfs_check_options() doesn't really do manycomplex checks, but hard RO requirement and some feature dependencychecks, thus there is no special reason not to do the check for mountreconfiguration.

A Information Disclosure vulnerability has been identified in the Squid web caching proxy, affecting versions prior to 7.2. This flaw occurs when the application fails to properly redact sensitive Hypertext Transfer Protocol (HTTP) authentication credentials from an error response. A remote client can exploit this by triggering an error condition, which allows a malicious script to bypass browser security and disclose the username and password a trusted client uses for access. This directly compromises the security of internal application credentials and security tokens, especially when Squid is configured for backend load balancing.

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\nfutex: Use correct exit on failure from futex_hash_allocate_default()\ncopy_process() uses the wrong error exit path from futex_hash_allocate_default().\nAfter exiting from futex_hash_allocate_default(), neither tasklist_lock\nnor siglock has been acquired. The exit label bad_fork_core_free unlocks\nboth of these locks which is wrong.\nThe next exit label, bad_fork_cancel_cgroup, is the correct exit.\nsched_cgroup_fork() did not allocate any resources that need to freed.\nUse bad_fork_cancel_cgroup on error exit from futex_hash_allocate_default().

No description is available for this CVE.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan't be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn't in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough. memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic. The race is as\nfollows:\n\ncpu0 cpu1\n shrink_folio_list memory_failure\n TestSetPageHWPoison\n unmap_poisoned_folio\n --> trigger BUG_ON due to\n unmap_poisoned_folio couldn't\n handle large folio\n\n[tujinjiang@huawei.com: add comment to unmap_poisoned_folio()]

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix unbuffered write error handling\n\nIf all the subrequests in an unbuffered write stream fail, the subrequest\ncollector doesn't update the stream->transferred value and it retains its\ninitial LONG_MAX value. Unfortunately, if all active streams fail, then we\ntake the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to set\nin wreq->transferred - which is then returned from ->write_iter().\n\nLONG_MAX was chosen as the initial value so that all the streams can be\nquickly assessed by taking the smallest value of all stream->transferred -\nbut this only works if we've set any of them.\n\nFix this by adding a flag to indicate whether the value in\nstream->transferred is valid and checking that when we integrate the\nvalues. stream->transferred can then be initialised to zero.\n\nThis was found by running the generic/750 xfstest against cifs with\ncache=none. It splices data to the target file. Once (if) it has used up\nall the available scratch space, the writes start failing with ENOSPC.\nThis causes ->write_iter() to fail. However, it was returning\nwreq->transferred, i.e. LONG_MAX, rather than an error (because it thought\nthe amount transferred was non-zero) and iter_file_splice_write() would\nthen try to clean up that amount of pipe bufferage - leading to an oops\nwhen it overran. The kernel log showed:\n\n CIFS: VFS: Send error in write = -28\n\nfollowed by:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n\nwith:\n\n RIP: 0010:iter_file_splice_write+0x3a4/0x520\n do_splice+0x197/0x4e0\n\nor:\n\n RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282)\n iter_file_splice_write (fs/splice.c:755)\n\nAlso put a warning check into splice to announce if ->write_iter() returned\nthat it had written more than it was asked to.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP\n\nSince the CAAM on these SoCs is managed by another ARM core, called the\nSECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which\nalso reserves access to register page 0 suspend operations cannot touch\nthis page.\n\nThis is similar to when running OPTEE, where OPTEE will reserve page 0.\n\nTrack this situation using a new state variable no_page0, reflecting if\npage 0 is reserved elsewhere, either by other management cores in SoC or\nby OPTEE.\n\nReplace the optee_en check in suspend/resume with the new check.\n\noptee_en cannot go away as it's needed elsewhere to gate OPTEE specific\nsituations.\n\nFixes the following splat at suspend:\n\n Internal error: synchronous external abort: 0000000096000010 [#1] SMP\n Hardware name: Freescale i.MX8QXP ACU6C (DT)\n pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : readl+0x0/0x18\n lr : rd_reg32+0x18/0x3c\n sp : ffffffc08192ba20\n x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000\n x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090\n x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010\n x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5\n x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c\n x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001\n x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000\n x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002\n x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000\n x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004\n Call trace:\n readl+0x0/0x18\n caam_ctrl_suspend+0x30/0xdc\n dpm_run_callback.constprop.0+0x24/0x5c\n device_suspend+0x170/0x2e8\n dpm_suspend+0xa0/0x104\n dpm_suspend_start+0x48/0x50\n suspend_devices_and_enter+0x7c/0x45c\n pm_suspend+0x148/0x160\n state_store+0xb4/0xf8\n kobj_attr_store+0x14/0x24\n sysfs_kf_write+0x38/0x48\n kernfs_fop_write_iter+0xb4/0x178\n vfs_write+0x118/0x178\n ksys_write+0x6c/0xd0\n __arm64_sys_write+0x14/0x1c\n invoke_syscall.constprop.0+0x64/0xb0\n do_el0_svc+0x90/0xb0\n el0_svc+0x18/0x44\n el0t_64_sync_handler+0x88/0x124\n el0t_64_sync+0x150/0x154\n Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000)

In the Linux kernel, the following vulnerability has been resolved:\n\nopen_tree_attr: do not allow id-mapping changes without OPEN_TREE_CLONE\n\nAs described in commit 7a54947e727b ('Merge patch series "fs: allow\nchanging idmappings"'), open_tree_attr(2) was necessary in order to\nallow for a detached mount to be created and have its idmappings changed\nwithout the risk of any racing threads operating on it. For this reason,\nmount_setattr(2) still does not allow for id-mappings to be changed.\n\nHowever, there was a bug in commit 2462651ffa76 ("fs: allow changing\nidmappings") which allowed users to bypass this restriction by calling\nopen_tree_attr(2) *without* OPEN_TREE_CLONE.\n\ncan_idmap_mount() prevented this bug from allowing an attached\nmountpoint's id-mapping from being modified (thanks to an is_anon_ns()\ncheck), but this still allows for detached (but visible) mounts to have\ntheir be id-mapping changed. This risks the same UAF and locking issues\nas described in the merge commit, and was likely unintentional.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval\n\nGetting / Setting the frame interval using the V4L2 subdev pad ops\nget_frame_interval/set_frame_interval causes a deadlock, as the\nsubdev state is locked in the [1] but also in the driver itself.\n\nIn [2] it's described that the caller is responsible to acquire and\nrelease the lock in this case. Therefore, acquiring the lock in the\ndriver is wrong.\n\nRemove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval()\nand mt9m114_ifp_set_frame_interval().\n\n[1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129\n[2] Documentation/driver-api/media/v4l2-subdev.rst

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: iris: Fix NULL pointer dereference\n\nA warning reported by smatch indicated a possible null pointer\ndereference where one of the arguments to API\n"iris_hfi_gen2_handle_system_error" could sometimes be null.\n\nTo fix this, add a check to validate that the argument passed is not\nnull before accessing its members.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/ops-common: ignore migration request to invalid nodes\n\ndamon_migrate_pages() tries migration even if the target node is invalid. \nIf users mistakenly make such invalid requests via\nDAMOS_MIGRATE_{HOT,COLD} action, the below kernel BUG can happen.\n\n [ 7831.883495] BUG: unable to handle page fault for address: 0000000000001f48\n [ 7831.884160] #PF: supervisor read access in kernel mode\n [ 7831.884681] #PF: error_code(0x0000) - not-present page\n [ 7831.885203] PGD 0 P4D 0\n [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI\n [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0 Not tainted 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(voluntary)\n [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.el9 04/01/2014\n [ 7831.887777] RIP: 0010:__alloc_frozen_pages_noprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/page_alloc.c:4936 mm/page_alloc.c:5137)\n [...]\n [ 7831.895953] Call Trace:\n [ 7831.896195] \n [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192)\n [ 7831.896787] migrate_pages_batch (mm/migrate.c:1189 mm/migrate.c:1851)\n [ 7831.897228] ? __pfx_alloc_migration_target (mm/migrate.c:2137)\n [ 7831.897735] migrate_pages (mm/migrate.c:2078)\n [ 7831.898141] ? __pfx_alloc_migration_target (mm/migrate.c:2137)\n [ 7831.898664] damon_migrate_folio_list (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354)\n [ 7831.899140] damon_migrate_pages (mm/damon/ops-common.c:405)\n [...]\n\nAdd a target node validity check in damon_migrate_pages(). The validity\ncheck is stolen from that of do_pages_move(), which is being used for the\nmove_pages() system call.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/riscv: prevent NULL deref in iova_to_phys\n\nThe riscv_iommu_pte_fetch() function returns either NULL for\nunmapped/never-mapped iova, or a valid leaf pte pointer that\nrequires no further validation.\n\nriscv_iommu_iova_to_phys() failed to handle NULL returns.\nPrevent null pointer dereference in\nriscv_iommu_iova_to_phys(), and remove the pte validation.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/futex: ensure io_futex_wait() cleans up properly on failure\n\nThe io_futex_data is allocated upfront and assigned to the io_kiocb\nasync_data field, but the request isn't marked with REQ_F_ASYNC_DATA\nat that point. Those two should always go together, as the flag tells\nio_uring whether the field is valid or not.\n\nAdditionally, on failure cleanup, the futex handler frees the data but\ndoes not clear ->async_data. Clear the data and the flag in the error\npath as well.\n\nThanks to Trend Micro Zero Day Initiative and particularly ReDress for\nreporting this.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: tas2781: Fix wrong reference of tasdevice_priv\n\nDuring the conversion to unify the calibration data management, the\nreference to tasdevice_priv was wrongly set to h->hda_priv instead of\nh->priv. This resulted in memory corruption and crashes eventually.\nUnfortunately it's a void pointer, hence the compiler couldn't know\nthat it's wrong.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Flush delayed SKBs while releasing RXE resources\n\nWhen skb packets are sent out, these skb packets still depends on\nthe rxe resources, for example, QP, sk, when these packets are\ndestroyed.\n\nIf these rxe resources are released when the skb packets are destroyed,\nthe call traces will appear.\n\nTo avoid skb packets hang too long time in some network devices,\na timestamp is added when these skb packets are created. If these\nskb packets hang too long time in network devices, these network\ndevices can free these skb packets to release rxe resources.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: accel: sca3300: fix uninitialized iio scan data\n\nFix potential leak of uninitialized stack data to userspace by ensuring\nthat the `channels` array is zeroed before use.

In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer\n\nThe data->block[0] variable comes from user. Without proper check,\nthe variable may be very large to cause an out-of-bounds bug.\n\nFix this bug by checking the value of data->block[0] first.\n\n1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in\n ismt_access()")\n2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in\n xgene_slimpro_i2c_xfer()")

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL\n\nIf metric table address is not allocated, accessing metrics_bin will\nresult in a NULL pointer dereference, so add a check.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: ufs-qcom: Fix ESI null pointer dereference\n\nESI/MSI is a performance optimization feature that provides dedicated\ninterrupts per MCQ hardware queue. This is optional feature and UFS MCQ\nshould work with and without ESI feature.\n\nCommit e46a28cea29a ("scsi: ufs: qcom: Remove the MSI descriptor abuse")\nbrings a regression in ESI (Enhanced System Interrupt) configuration that\ncauses a null pointer dereference when Platform MSI allocation fails.\n\nThe issue occurs in when platform_device_msi_init_and_alloc_irqs() in\nufs_qcom_config_esi() fails (returns -EINVAL) but the current code uses\n__free() macro for automatic cleanup free MSI resources that were never\nsuccessfully allocated.\n\nUnable to handle kernel NULL pointer dereference at virtual\naddress 0000000000000008\n\n Call trace:\n mutex_lock+0xc/0x54 (P)\n platform_device_msi_free_irqs_all+0x1c/0x40\n ufs_qcom_config_esi+0x1d0/0x220 [ufs_qcom]\n ufshcd_config_mcq+0x28/0x104\n ufshcd_init+0xa3c/0xf40\n ufshcd_pltfrm_init+0x504/0x7d4\n ufs_qcom_probe+0x20/0x58 [ufs_qcom]\n\nFix by restructuring the ESI configuration to try MSI allocation first,\nbefore any other resource allocation and instead use explicit cleanup\ninstead of __free() macro to avoid cleanup of unallocated resources.\n\nTested on SM8750 platform with MCQ enabled, both with and without\nPlatform ESI support.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix oops due to uninitialised variable\n\nFix smb3_init_transform_rq() to initialise buffer to NULL before calling\nnetfs_alloc_folioq_buffer() as netfs assumes it can append to the buffer it\nis given. Setting it to NULL means it should start a fresh buffer, but the\nvalue is currently undefined.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: asix_devices: Fix PHY address mask in MDIO bus initialization\n\nSyzbot reported shift-out-of-bounds exception on MDIO bus initialization.\n\nThe PHY address should be masked to 5 bits (0-31). Without this\nmask, invalid PHY addresses could be used, potentially causing issues\nwith MDIO bus operations.\n\nFix this by masking the PHY address with 0x1f (31 decimal) to ensure\nit stays within the valid range.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/mm: Do not map lowcore with identity mapping\n\nSince the identity mapping is pinned to address zero the lowcore is always\nalso mapped to address zero, this happens regardless of the relocate_lowcore\ncommand line option. If the option is specified the lowcore is mapped\ntwice, instead of only once.\n\nThis means that NULL pointer accesses will succeed instead of causing an\nexception (low address protection still applies, but covers only parts).\nTo fix this never map the first two pages of physical memory with the\nidentity mapping.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix vm_bind_ioctl double free bug\n\nIf the argument check during an array bind fails, the bind_ops are freed\ntwice as seen below. Fix this by setting bind_ops to NULL after freeing.\n\n==================================================================\nBUG: KASAN: double-free in xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\nFree of addr ffff88813bb9b800 by task xe_vm/14198\n\nCPU: 5 UID: 0 PID: 14198 Comm: xe_vm Not tainted 6.16.0-xe-eudebug-cmanszew+ #520 PREEMPT(full)\nHardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2411.A02.2110081023 10/08/2021\nCall Trace:\n \n dump_stack_lvl+0x82/0xd0\n print_report+0xcb/0x610\n ? __virt_addr_valid+0x19a/0x300\n ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n kasan_report_invalid_free+0xc8/0xf0\n ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n check_slab_allocation+0x102/0x130\n kfree+0x10d/0x440\n ? should_fail_ex+0x57/0x2f0\n ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]\n ? __lock_acquire+0xab9/0x27f0\n ? lock_acquire+0x165/0x300\n ? drm_dev_enter+0x53/0xe0 [drm]\n ? find_held_lock+0x2b/0x80\n ? drm_dev_exit+0x30/0x50 [drm]\n ? drm_ioctl_kernel+0x128/0x1c0 [drm]\n drm_ioctl_kernel+0x128/0x1c0 [drm]\n ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]\n ? find_held_lock+0x2b/0x80\n ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm]\n ? should_fail_ex+0x57/0x2f0\n ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]\n drm_ioctl+0x352/0x620 [drm]\n ? __pfx_drm_ioctl+0x10/0x10 [drm]\n ? __pfx_rpm_resume+0x10/0x10\n ? do_raw_spin_lock+0x11a/0x1b0\n ? find_held_lock+0x2b/0x80\n ? __pm_runtime_resume+0x61/0xc0\n ? rcu_is_watching+0x20/0x50\n ? trace_irq_enable.constprop.0+0xac/0xe0\n xe_drm_ioctl+0x91/0xc0 [xe]\n __x64_sys_ioctl+0xb2/0x100\n ? rcu_is_watching+0x20/0x50\n do_syscall_64+0x68/0x2e0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fa9acb24ded\n\n(cherry picked from commit a01b704527c28a2fd43a17a85f8996b75ec8492a)