Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix kernel bug due to missing clearing of checked flag<br /> <br /> Syzbot reported that in directory operations after nilfs2 detects<br /> filesystem corruption and degrades to read-only,<br /> __block_write_begin_int(), which is called to prepare block writes, may<br /> fail the BUG_ON check for accesses exceeding the folio/page size,<br /> triggering a kernel bug.<br /> <br /> This was found to be because the "checked" flag of a page/folio was not<br /> cleared when it was discarded by nilfs2&amp;#39;s own routine, which causes the<br /> sanity check of directory entries to be skipped when the directory<br /> page/folio is reloaded. So, fix that.<br /> <br /> This was necessary when the use of nilfs2&amp;#39;s own page discard routine was<br /> applied to more than just metadata files.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()<br /> <br /> Mounting btrfs from two images (which have the same one fsid and two<br /> different dev_uuids) in certain executing order may trigger an UAF for<br /> variable &amp;#39;device-&gt;bdev_file&amp;#39; in __btrfs_free_extra_devids(). And<br /> following are the details:<br /> <br /> 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs<br /> devices by ioctl(BTRFS_IOC_SCAN_DEV):<br /> <br /> / btrfs_device_1 → loop0<br /> fs_device<br /> \ btrfs_device_2 → loop1<br /> 2. mount /dev/loop0 /mnt<br /> btrfs_open_devices<br /> btrfs_device_1-&gt;bdev_file = btrfs_get_bdev_and_sb(loop0)<br /> btrfs_device_2-&gt;bdev_file = btrfs_get_bdev_and_sb(loop1)<br /> btrfs_fill_super<br /> open_ctree<br /> fail: btrfs_close_devices // -ENOMEM<br /> btrfs_close_bdev(btrfs_device_1)<br /> fput(btrfs_device_1-&gt;bdev_file)<br /> // btrfs_device_1-&gt;bdev_file is freed<br /> btrfs_close_bdev(btrfs_device_2)<br /> fput(btrfs_device_2-&gt;bdev_file)<br /> <br /> 3. mount /dev/loop1 /mnt<br /> btrfs_open_devices<br /> btrfs_get_bdev_and_sb(&amp;bdev_file)<br /> // EIO, btrfs_device_1-&gt;bdev_file is not assigned,<br /> // which points to a freed memory area<br /> btrfs_device_2-&gt;bdev_file = btrfs_get_bdev_and_sb(loop1)<br /> btrfs_fill_super<br /> open_ctree<br /> btrfs_free_extra_devids<br /> if (btrfs_device_1-&gt;bdev_file)<br /> fput(btrfs_device_1-&gt;bdev_file) // UAF !<br /> <br /> Fix it by setting &amp;#39;device-&gt;bdev_file&amp;#39; as &amp;#39;NULL&amp;#39; after closing the<br /> btrfs_device in btrfs_close_one_device().

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 /> fork: do not invoke uffd on fork if error occurs<br /> <br /> Patch series "fork: do not expose incomplete mm on fork".<br /> <br /> During fork we may place the virtual memory address space into an<br /> inconsistent state before the fork operation is complete.<br /> <br /> In addition, we may encounter an error during the fork operation that<br /> indicates that the virtual memory address space is invalidated.<br /> <br /> As a result, we should not be exposing it in any way to external machinery<br /> that might interact with the mm or VMAs, machinery that is not designed to<br /> deal with incomplete state.<br /> <br /> We specifically update the fork logic to defer khugepaged and ksm to the<br /> end of the operation and only to be invoked if no error arose, and<br /> disallow uffd from observing fork events should an error have occurred.<br /> <br /> <br /> This patch (of 2):<br /> <br /> Currently on fork we expose the virtual address space of a process to<br /> userland unconditionally if uffd is registered in VMAs, regardless of<br /> whether an error arose in the fork.<br /> <br /> This is performed in dup_userfaultfd_complete() which is invoked<br /> unconditionally, and performs two duties - invoking registered handlers<br /> for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down<br /> userfaultfd_fork_ctx objects established in dup_userfaultfd().<br /> <br /> This is problematic, because the virtual address space may not yet be<br /> correctly initialised if an error arose.<br /> <br /> The change in commit d24062914837 ("fork: use __mt_dup() to duplicate<br /> maple tree in dup_mmap()") makes this more pertinent as we may be in a<br /> state where entries in the maple tree are not yet consistent.<br /> <br /> We address this by, on fork error, ensuring that we roll back state that<br /> we would otherwise expect to clean up through the event being handled by<br /> userland and perform the memory freeing duty otherwise performed by<br /> dup_userfaultfd_complete().<br /> <br /> We do this by implementing a new function, dup_userfaultfd_fail(), which<br /> performs the same loop, only decrementing reference counts.<br /> <br /> Note that we perform mmgrab() on the parent and child mm&amp;#39;s, however<br /> userfaultfd_ctx_put() will mmdrop() this once the reference count drops to<br /> zero, so we will avoid memory leaks correctly here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Vangogh: Fix kernel memory out of bounds write<br /> <br /> KASAN reports that the GPU metrics table allocated in<br /> vangogh_tables_init() is not large enough for the memset done in<br /> smu_cmn_init_soft_gpu_metrics(). Condensed report follows:<br /> <br /> [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu]<br /> [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067<br /> ...<br /> [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544<br /> [ 33.861816] Tainted: [W]=WARN<br /> [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023<br /> [ 33.861822] Call Trace:<br /> [ 33.861826] <br /> [ 33.861829] dump_stack_lvl+0x66/0x90<br /> [ 33.861838] print_report+0xce/0x620<br /> [ 33.861853] kasan_report+0xda/0x110<br /> [ 33.862794] kasan_check_range+0xfd/0x1a0<br /> [ 33.862799] __asan_memset+0x23/0x40<br /> [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.867135] dev_attr_show+0x43/0xc0<br /> [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0<br /> [ 33.867155] seq_read_iter+0x3f8/0x1140<br /> [ 33.867173] vfs_read+0x76c/0xc50<br /> [ 33.867198] ksys_read+0xfb/0x1d0<br /> [ 33.867214] do_syscall_64+0x90/0x160<br /> ...<br /> [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s:<br /> [ 33.867358] kasan_save_stack+0x33/0x50<br /> [ 33.867364] kasan_save_track+0x17/0x60<br /> [ 33.867367] __kasan_kmalloc+0x87/0x90<br /> [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu]<br /> [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu]<br /> [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu]<br /> [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu]<br /> [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu]<br /> [ 33.869608] local_pci_probe+0xda/0x180<br /> [ 33.869614] pci_device_probe+0x43f/0x6b0<br /> <br /> Empirically we can confirm that the former allocates 152 bytes for the<br /> table, while the latter memsets the 168 large block.<br /> <br /> Root cause appears that when GPU metrics tables for v2_4 parts were added<br /> it was not considered to enlarge the table to fit.<br /> <br /> The fix in this patch is rather "brute force" and perhaps later should be<br /> done in a smarter way, by extracting and consolidating the part version to<br /> size logic to a common helper, instead of brute forcing the largest<br /> possible allocation. Nevertheless, for now this works and fixes the out of<br /> bounds write.<br /> <br /> v2:<br /> * Drop impossible v3_0 case. (Mario)<br /> <br /> (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP<br /> <br /> generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem,<br /> on huge=always tmpfs, issues a warning and then hangs (interruptibly):<br /> <br /> WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9<br /> CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2<br /> ...<br /> copy_page_from_iter_atomic+0xa6/0x5ec<br /> generic_perform_write+0xf6/0x1b4<br /> shmem_file_write_iter+0x54/0x67<br /> <br /> Fix copy_page_from_iter_atomic() by limiting it in that case<br /> (include/linux/skbuff.h skb_frag_must_loop() does similar).<br /> <br /> But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too<br /> surprising, has outlived its usefulness, and should just be removed?

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/numa: Fix the potential null pointer dereference in task_numa_work()<br /> <br /> When running stress-ng-vm-segv test, we found a null pointer dereference<br /> error in task_numa_work(). Here is the backtrace:<br /> <br /> [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> ......<br /> [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se<br /> ......<br /> [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--)<br /> [323676.067115] pc : vma_migratable+0x1c/0xd0<br /> [323676.067122] lr : task_numa_work+0x1ec/0x4e0<br /> [323676.067127] sp : ffff8000ada73d20<br /> [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010<br /> [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000<br /> [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000<br /> [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8<br /> [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035<br /> [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8<br /> [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4<br /> [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001<br /> [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000<br /> [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000<br /> [323676.067152] Call trace:<br /> [323676.067153] vma_migratable+0x1c/0xd0<br /> [323676.067155] task_numa_work+0x1ec/0x4e0<br /> [323676.067157] task_work_run+0x78/0xd8<br /> [323676.067161] do_notify_resume+0x1ec/0x290<br /> [323676.067163] el0_svc+0x150/0x160<br /> [323676.067167] el0t_64_sync_handler+0xf8/0x128<br /> [323676.067170] el0t_64_sync+0x17c/0x180<br /> [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000)<br /> [323676.067177] SMP: stopping secondary CPUs<br /> [323676.070184] Starting crashdump kernel...<br /> <br /> stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error<br /> handling function of the system, which tries to cause a SIGSEGV error on<br /> return from unmapping the whole address space of the child process.<br /> <br /> Normally this program will not cause kernel crashes. But before the<br /> munmap system call returns to user mode, a potential task_numa_work()<br /> for numa balancing could be added and executed. In this scenario, since the<br /> child process has no vma after munmap, the vma_next() in task_numa_work()<br /> will return a null pointer even if the vma iterator restarts from 0.<br /> <br /> Recheck the vma pointer before dereferencing it in task_numa_work().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-fsl-dspi: Fix crash when not using GPIO chip select<br /> <br /> Add check for the return value of spi_get_csgpiod() to avoid passing a NULL<br /> pointer to gpiod_direction_output(), preventing a crash when GPIO chip<br /> select is not used.<br /> <br /> Fix below crash:<br /> [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 4.260762] Mem abort info:<br /> [ 4.263556] ESR = 0x0000000096000004<br /> [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 4.272624] SET = 0, FnV = 0<br /> [ 4.275681] EA = 0, S1PTW = 0<br /> [ 4.278822] FSC = 0x04: level 0 translation fault<br /> [ 4.283704] Data abort info:<br /> [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 4.302445] [0000000000000000] user address but active_mm is swapper<br /> [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 4.315072] Modules linked in:<br /> [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359<br /> [ 4.328130] Hardware name: LS1046A QDS Board (DT)<br /> [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 4.339794] pc : gpiod_direction_output+0x34/0x5c<br /> [ 4.344505] lr : gpiod_direction_output+0x18/0x5c<br /> [ 4.349208] sp : ffff80008003b8f0<br /> [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068<br /> [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810<br /> [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002<br /> [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff<br /> [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007<br /> [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e<br /> [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008<br /> [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000<br /> [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000<br /> [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 4.423921] Call trace:<br /> [ 4.426362] gpiod_direction_output+0x34/0x5c (P)<br /> [ 4.431067] gpiod_direction_output+0x18/0x5c (L)<br /> [ 4.435771] dspi_setup+0x220/0x334

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix error propagation of split bios<br /> <br /> The purpose of btrfs_bbio_propagate_error() shall be propagating an error<br /> of split bio to its original btrfs_bio, and tell the error to the upper<br /> layer. However, it&amp;#39;s not working well on some cases.<br /> <br /> * Case 1. Immediate (or quick) end_bio with an error<br /> <br /> When btrfs sends btrfs_bio to mirrored devices, btrfs calls<br /> btrfs_bio_end_io() when all the mirroring bios are completed. If that<br /> btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function<br /> is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error()<br /> accesses the orig_bbio&amp;#39;s bio context to increase the error count.<br /> <br /> That works well in most cases. However, if the end_io is called enough<br /> fast, orig_bbio&amp;#39;s (remaining part after split) bio context may not be<br /> properly set at that time. Since the bio context is set when the orig_bbio<br /> (the last btrfs_bio) is sent to devices, that might be too late for earlier<br /> split btrfs_bio&amp;#39;s completion. That will result in NULL pointer<br /> dereference.<br /> <br /> That bug is easily reproducible by running btrfs/146 on zoned devices [1]<br /> and it shows the following trace.<br /> <br /> [1] You need raid-stripe-tree feature as it create "-d raid0 -m raid1" FS.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474<br /> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> Workqueue: writeback wb_workfn (flush-btrfs-5)<br /> RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs]<br /> BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0<br /> RSP: 0018:ffffc9000006f248 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc<br /> RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080<br /> RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001<br /> R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58<br /> R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158<br /> FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x26<br /> ? page_fault_oops+0x13e/0x2b0<br /> ? _printk+0x58/0x73<br /> ? do_user_addr_fault+0x5f/0x750<br /> ? exc_page_fault+0x76/0x240<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? btrfs_bio_end_io+0xae/0xc0 [btrfs]<br /> ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs]<br /> btrfs_orig_write_end_io+0x51/0x90 [btrfs]<br /> dm_submit_bio+0x5c2/0xa50 [dm_mod]<br /> ? find_held_lock+0x2b/0x80<br /> ? blk_try_enter_queue+0x90/0x1e0<br /> __submit_bio+0xe0/0x130<br /> ? ktime_get+0x10a/0x160<br /> ? lockdep_hardirqs_on+0x74/0x100<br /> submit_bio_noacct_nocheck+0x199/0x410<br /> btrfs_submit_bio+0x7d/0x150 [btrfs]<br /> btrfs_submit_chunk+0x1a1/0x6d0 [btrfs]<br /> ? lockdep_hardirqs_on+0x74/0x100<br /> ? __folio_start_writeback+0x10/0x2c0<br /> btrfs_submit_bbio+0x1c/0x40 [btrfs]<br /> submit_one_bio+0x44/0x60 [btrfs]<br /> submit_extent_folio+0x13f/0x330 [btrfs]<br /> ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs]<br /> extent_writepage_io+0x18b/0x360 [btrfs]<br /> extent_write_locked_range+0x17c/0x340 [btrfs]<br /> ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs]<br /> run_delalloc_cow+0x71/0xd0 [btrfs]<br /> btrfs_run_delalloc_range+0x176/0x500 [btrfs]<br /> ? find_lock_delalloc_range+0x119/0x260 [btrfs]<br /> writepage_delalloc+0x2ab/0x480 [btrfs]<br /> extent_write_cache_pages+0x236/0x7d0 [btrfs]<br /> btrfs_writepages+0x72/0x130 [btrfs]<br /> do_writepages+0xd4/0x240<br /> ? find_held_lock+0x2b/0x80<br /> ? wbc_attach_and_unlock_inode+0x12c/0x290<br /> ? wbc_attach_and_unlock_inode+0x12c/0x29<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow<br /> <br /> Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two<br /> reasons for this: first, the parameter value passed is greater than<br /> ocfs2_max_inline_data_with_xattr, second, the start and end parameters of<br /> ocfs2_truncate_inline are "unsigned int".<br /> <br /> So, we need to add a sanity check for byte_start and byte_len right before<br /> ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater<br /> than ocfs2_max_inline_data_with_xattr return -EINVAL.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()<br /> <br /> modprobe drm_connector_test and then rmmod drm_connector_test,<br /> the following memory leak occurs.<br /> <br /> The `mode` allocated in drm_mode_duplicate() called by<br /> drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:<br /> <br /> unreferenced object 0xffffff80cb0ee400 (size 128):<br /> comm "kunit_try_catch", pid 1948, jiffies 4294950339<br /> hex dump (first 32 bytes):<br /> 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8.<br /> 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00