Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wireguard: netlink: check for dangling peer via is_dead instead of empty list<br /> <br /> If all peers are removed via wg_peer_remove_all(), rather than setting<br /> peer_list to empty, the peer is added to a temporary list with a head on<br /> the stack of wg_peer_remove_all(). If a netlink dump is resumed and the<br /> cursored peer is one that has been removed via wg_peer_remove_all(), it<br /> will iterate from that peer and then attempt to dump freed peers.<br /> <br /> Fix this by instead checking peer-&gt;is_dead, which was explictly created<br /> for this purpose. Also move up the device_update_lock lockdep assertion,<br /> since reading is_dead relies on that.<br /> <br /> It can be reproduced by a small script like:<br /> <br /> echo "Setting config..."<br /> ip link add dev wg0 type wireguard<br /> wg setconf wg0 /big-config<br /> (<br /> while true; do<br /> echo "Showing config..."<br /> wg showconf wg0 &gt; /dev/null<br /> done<br /> ) &amp;<br /> sleep 4<br /> wg setconf wg0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix failure to detect DAT corruption in btree and direct mappings<br /> <br /> Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".<br /> <br /> This resolves a kernel BUG reported by syzbot. Since there are two<br /> flaws involved, I&amp;#39;ve made each one a separate patch.<br /> <br /> The first patch alone resolves the syzbot-reported bug, but I think<br /> both fixes should be sent to stable, so I&amp;#39;ve tagged them as such.<br /> <br /> <br /> This patch (of 2):<br /> <br /> Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data<br /> to a nilfs2 file system whose metadata is corrupted.<br /> <br /> There are two flaws involved in this issue.<br /> <br /> The first flaw is that when nilfs_get_block() locates a data block using<br /> btree or direct mapping, if the disk address translation routine<br /> nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata<br /> corruption, it can be passed back to nilfs_get_block(). This causes<br /> nilfs_get_block() to misidentify an existing block as non-existent,<br /> causing both data block lookup and insertion to fail inconsistently.<br /> <br /> The second flaw is that nilfs_get_block() returns a successful status in<br /> this inconsistent state. This causes the caller __block_write_begin_int()<br /> or others to request a read even though the buffer is not mapped,<br /> resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()<br /> failing.<br /> <br /> This fixes the first issue by changing the return value to code -EINVAL<br /> when a conversion using DAT fails with code -ENOENT, avoiding the<br /> conflicting condition that leads to the kernel bug described above. Here,<br /> code -EINVAL indicates that metadata corruption was detected during the<br /> block lookup, which will be properly handled as a file system error and<br /> converted to -EIO when passing through the nilfs2 bmap layer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: prevent kernel bug at submit_bh_wbc()<br /> <br /> Fix a bug where nilfs_get_block() returns a successful status when<br /> searching and inserting the specified block both fail inconsistently. If<br /> this inconsistent behavior is not due to a previously fixed bug, then an<br /> unexpected race is occurring, so return a temporary error -EAGAIN instead.<br /> <br /> This prevents callers such as __block_write_begin_int() from requesting a<br /> read into a buffer that is not mapped, which would cause the BUG_ON check<br /> for the BH_Mapped flag in submit_bh_wbc() to fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix potencial out-of-bounds when buffer offset is invalid<br /> <br /> I found potencial out-of-bounds when buffer offset fields of a few requests<br /> is invalid. This patch set the minimum value of buffer offset field to<br /> -&gt;Buffer offset to validate buffer length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()<br /> <br /> If -&gt;NameOffset of smb2_create_req is smaller than Buffer offset of<br /> smb2_create_req, slab-out-of-bounds read can happen from smb2_open.<br /> This patch set the minimum value of the name offset to the buffer offset<br /> to validate name length of smb2_create_req().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: iaa - Fix nr_cpus

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address<br /> <br /> Read from an unsafe address with copy_from_kernel_nofault() in<br /> arch_adjust_kprobe_addr() because this function is used before checking<br /> the address is in text or not. Syzcaller bot found a bug and reported<br /> the case if user specifies inaccessible data area,<br /> arch_adjust_kprobe_addr() will cause a kernel panic.<br /> <br /> [ mingo: Clarified the comment. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses<br /> <br /> Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account<br /> freed memory map alignment") changes the semantics of pfn_valid() to check<br /> presence of the memory map for a PFN. A valid page for an address which<br /> is reserved but not mapped by the kernel[1], the system crashed during<br /> some uio test with the following memory layout:<br /> <br /> node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff]<br /> node 0: [mem 0x00000000d0000000-0x00000000da1fffff]<br /> the uio layout is：0xc0900000, 0x100000<br /> <br /> the crash backtrace like:<br /> <br /> Unable to handle kernel paging request at virtual address bff00000<br /> [...]<br /> CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1<br /> Hardware name: Generic DT based system<br /> PC is at b15_flush_kern_dcache_area+0x24/0x3c<br /> LR is at __sync_icache_dcache+0x6c/0x98<br /> [...]<br /> (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)<br /> (__sync_icache_dcache) from (set_pte_at+0x28/0x54)<br /> (set_pte_at) from (remap_pfn_range+0x1a0/0x274)<br /> (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])<br /> (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)<br /> (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)<br /> (__do_mmap_mm) from (do_mmap+0x50/0x58)<br /> (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)<br /> (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)<br /> (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)<br /> Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)<br /> ---[ end trace 09cf0734c3805d52 ]---<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> So check if PG_reserved was set to solve this issue.<br /> <br /> [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add a dc_state NULL check in dc_state_release<br /> <br /> [How]<br /> Check wheather state is NULL before releasing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/pm: Fix NULL pointer dereference when get power limit<br /> <br /> Because powerplay_table initialization is skipped under<br /> sriov case, We check and set default lower and upper OD<br /> value if powerplay_table is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: fix use-after-free in do_zone_finish()<br /> <br /> Shinichiro reported the following use-after-free triggered by the device<br /> replace operation in fstests btrfs/070.<br /> <br /> BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs]<br /> Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007<br /> <br /> CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1<br /> Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5b/0x90<br /> print_report+0xcf/0x670<br /> ? __virt_addr_valid+0x200/0x3e0<br /> kasan_report+0xd8/0x110<br /> ? do_zone_finish+0x91a/0xb90 [btrfs]<br /> ? do_zone_finish+0x91a/0xb90 [btrfs]<br /> do_zone_finish+0x91a/0xb90 [btrfs]<br /> btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs]<br /> ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs]<br /> ? btrfs_put_root+0x2d/0x220 [btrfs]<br /> ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs]<br /> cleaner_kthread+0x21e/0x380 [btrfs]<br /> ? __pfx_cleaner_kthread+0x10/0x10 [btrfs]<br /> kthread+0x2e3/0x3c0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> Allocated by task 3493983:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0xaa/0xb0<br /> btrfs_alloc_device+0xb3/0x4e0 [btrfs]<br /> device_list_add.constprop.0+0x993/0x1630 [btrfs]<br /> btrfs_scan_one_device+0x219/0x3d0 [btrfs]<br /> btrfs_control_ioctl+0x26e/0x310 [btrfs]<br /> __x64_sys_ioctl+0x134/0x1b0<br /> do_syscall_64+0x99/0x190<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> Freed by task 3494056:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3f/0x60<br /> poison_slab_object+0x102/0x170<br /> __kasan_slab_free+0x32/0x70<br /> kfree+0x11b/0x320<br /> btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs]<br /> btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs]<br /> btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs]<br /> btrfs_ioctl+0xb27/0x57d0 [btrfs]<br /> __x64_sys_ioctl+0x134/0x1b0<br /> do_syscall_64+0x99/0x190<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> The buggy address belongs to the object at ffff8881543c8000<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 96 bytes inside of<br /> freed 1024-byte region [ffff8881543c8000, ffff8881543c8400)<br /> <br /> The buggy address belongs to the physical page:<br /> page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8<br /> head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff)<br /> page_type: 0xffffffff()<br /> raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002<br /> raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> <br /> This UAF happens because we&amp;#39;re accessing stale zone information of a<br /> already removed btrfs_device in do_zone_finish().<br /> <br /> The sequence of events is as follows:<br /> <br /> btrfs_dev_replace_start<br /> btrfs_scrub_dev<br /> btrfs_dev_replace_finishing<br /> btrfs_dev_replace_update_device_in_mapping_tree

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/vma: Fix UAF on destroy against retire race<br /> <br /> Object debugging tools were sporadically reporting illegal attempts to<br /> free a still active i915 VMA object when parking a GT believed to be idle.<br /> <br /> [161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]<br /> [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0<br /> ...<br /> [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1<br /> [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022<br /> [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915]<br /> [161.360592] RIP: 0010:debug_print_object+0x80/0xb0<br /> ...<br /> [161.361347] debug_object_free+0xeb/0x110<br /> [161.361362] i915_active_fini+0x14/0x130 [i915]<br /> [161.361866] release_references+0xfe/0x1f0 [i915]<br /> [161.362543] i915_vma_parked+0x1db/0x380 [i915]<br /> [161.363129] __gt_park+0x121/0x230 [i915]<br /> [161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915]<br /> <br /> That has been tracked down to be happening when another thread is<br /> deactivating the VMA inside __active_retire() helper, after the VMA&amp;#39;s<br /> active counter has been already decremented to 0, but before deactivation<br /> of the VMA&amp;#39;s object is reported to the object debugging tool.<br /> <br /> We could prevent from that race by serializing i915_active_fini() with<br /> __active_retire() via ref-&gt;tree_lock, but that wouldn&amp;#39;t stop the VMA from<br /> being used, e.g. from __i915_vma_retire() called at the end of<br /> __active_retire(), after that VMA has been already freed by a concurrent<br /> i915_vma_destroy() on return from the i915_active_fini(). Then, we should<br /> rather fix the issue at the VMA level, not in i915_active.<br /> <br /> Since __i915_vma_parked() is called from __gt_park() on last put of the<br /> GT&amp;#39;s wakeref, the issue could be addressed by holding the GT wakeref long<br /> enough for __active_retire() to complete before that wakeref is released<br /> and the GT parked.<br /> <br /> I believe the issue was introduced by commit d93939730347 ("drm/i915:<br /> Remove the vma refcount") which moved a call to i915_active_fini() from<br /> a dropped i915_vma_release(), called on last put of the removed VMA kref,<br /> to i915_vma_parked() processing path called on last put of a GT wakeref.<br /> However, its visibility to the object debugging tool was suppressed by a<br /> bug in i915_active that was fixed two weeks later with commit e92eb246feb9<br /> ("drm/i915/active: Fix missing debug object activation").<br /> <br /> A VMA associated with a request doesn&amp;#39;t acquire a GT wakeref by itself.<br /> Instead, it depends on a wakeref held directly by the request&amp;#39;s active<br /> intel_context for a GT associated with its VM, and indirectly on that<br /> intel_context&amp;#39;s engine wakeref if the engine belongs to the same GT as the<br /> VMA&amp;#39;s VM. Those wakerefs are released asynchronously to VMA deactivation.<br /> <br /> Fix the issue by getting a wakeref for the VMA&amp;#39;s GT when activating it,<br /> and putting that wakeref only after the VMA is deactivated. However,<br /> exclude global GTT from that processing path, otherwise the GPU never goes<br /> idle. Since __i915_vma_retire() may be called from atomic contexts, use<br /> async variant of wakeref put. Also, to avoid circular locking dependency,<br /> take care of acquiring the wakeref before VM mutex when both are needed.<br /> <br /> v7: Add inline comments with justifications for:<br /> - using untracked variants of intel_gt_pm_get/put() (Nirmoy),<br /> - using async variant of _put(),<br /> - not getting the wakeref in case of a global GTT,<br /> - always getting the first wakeref outside vm-&gt;mutex.<br /> v6: Since __i915_vma_active/retire() callbacks are not serialized, storing<br /> a wakeref tracking handle inside struct i915_vma is not safe, and<br /> there is no other good place for that. Use untracked variants of<br /> intel_gt_pm_get/put_async().<br /> v5: Replace "tile" with "GT" across commit description (Rodrigo),<br /> - <br /> ---truncated---