Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: prevent kernel warning due to negative i_nlink from corrupted image<br /> <br /> WARNING: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0<br /> home/cc/linux/fs/inode.c:417<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted<br /> 6.14.0-12627-g94d471a4f428 #2 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417<br /> Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff<br /> f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90<br /> &amp;lt;0f&amp;gt; 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6<br /> ff<br /> RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f<br /> RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005<br /> RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000<br /> R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0<br /> FS: 000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> f2fs_i_links_write home/cc/linux/fs/f2fs/f2fs.h:3194 [inline]<br /> f2fs_drop_nlink+0xd1/0x3c0 home/cc/linux/fs/f2fs/dir.c:845<br /> f2fs_delete_entry+0x542/0x1450 home/cc/linux/fs/f2fs/dir.c:909<br /> f2fs_unlink+0x45c/0x890 home/cc/linux/fs/f2fs/namei.c:581<br /> vfs_unlink+0x2fb/0x9b0 home/cc/linux/fs/namei.c:4544<br /> do_unlinkat+0x4c5/0x6a0 home/cc/linux/fs/namei.c:4608<br /> __do_sys_unlink home/cc/linux/fs/namei.c:4654 [inline]<br /> __se_sys_unlink home/cc/linux/fs/namei.c:4652 [inline]<br /> __x64_sys_unlink+0xc5/0x110 home/cc/linux/fs/namei.c:4652<br /> do_syscall_x64 home/cc/linux/arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xc7/0x250 home/cc/linux/arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fb3d092324b<br /> Code: 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66<br /> 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 57 00 00 00 0f 05<br /> &amp;lt;48&amp;gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01<br /> 48<br /> RSP: 002b:00007ffdc232d938 EFLAGS: 00000206 ORIG_RAX: 0000000000000057<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb3d092324b<br /> RDX: 00007ffdc232d960 RSI: 00007ffdc232d960 RDI: 00007ffdc232d9f0<br /> RBP: 00007ffdc232d9f0 R08: 0000000000000001 R09: 00007ffdc232d7c0<br /> R10: 00000000fffffffd R11: 0000000000000206 R12: 00007ffdc232eaf0<br /> R13: 000055555d0cebb0 R14: 00007ffdc232d958 R15: 0000000000000001<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on sit_bitmap_size<br /> <br /> w/ below testcase, resize will generate a corrupted image which<br /> contains inconsistent metadata, so when mounting such image, it<br /> will trigger kernel panic:<br /> <br /> touch img<br /> truncate -s $((512*1024*1024*1024)) img<br /> mkfs.f2fs -f img $((256*1024*1024))<br /> resize.f2fs -s -i img -t $((1024*1024*1024))<br /> mount img /mnt/f2fs<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/segment.h:863!<br /> Oops: invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490<br /> <br /> Call Trace:<br /> f2fs_build_segment_manager+0x11c3/0x2600<br /> f2fs_fill_super+0xe97/0x2840<br /> mount_bdev+0xf4/0x140<br /> legacy_get_tree+0x2b/0x50<br /> vfs_get_tree+0x29/0xd0<br /> path_mount+0x487/0xaf0<br /> __x64_sys_mount+0x116/0x150<br /> do_syscall_64+0x82/0x190<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fdbfde1bcfe<br /> <br /> The reaseon is:<br /> <br /> sit_i-&gt;bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum<br /> there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt<br /> is 4762, build_sit_entries() -&gt; current_sit_addr() tries to access<br /> out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap<br /> and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on().<br /> <br /> Let&amp;#39;s add sanity check in f2fs_sanity_check_ckpt() to avoid panic.

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 /> configfs-tsm-report: Fix NULL dereference of tsm_ops<br /> <br /> Unlike sysfs, the lifetime of configfs objects is controlled by<br /> userspace. There is no mechanism for the kernel to find and delete all<br /> created config-items. Instead, the configfs-tsm-report mechanism has an<br /> expectation that tsm_unregister() can happen at any time and cause<br /> established config-item access to start failing.<br /> <br /> That expectation is not fully satisfied. While tsm_report_read(),<br /> tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail<br /> if tsm_ops have been unregistered, tsm_report_privlevel_store()<br /> tsm_report_provider_show() fail to check for ops registration. Add the<br /> missing checks for tsm_ops having been removed.<br /> <br /> Now, in supporting the ability for tsm_unregister() to always succeed,<br /> it leaves the problem of what to do with lingering config-items. The<br /> expectation is that the admin that arranges for the -&gt;remove() (unbind)<br /> of the ${tsm_arch}-guest driver is also responsible for deletion of all<br /> open config-items. Until that deletion happens, -&gt;probe() (reload /<br /> bind) of the ${tsm_arch}-guest driver fails.<br /> <br /> This allows for emergency shutdown / revocation of attestation<br /> interfaces, and requires coordinated restart.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-tcp: remove tag set when second admin queue config fails<br /> <br /> Commit 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure<br /> concatenation") modified nvme_tcp_setup_ctrl() to call<br /> nvme_tcp_configure_admin_queue() twice. The first call prepares for<br /> DH-CHAP negotitation, and the second call is required for secure<br /> concatenation. However, this change triggered BUG KASAN slab-use-after-<br /> free in blk_mq_queue_tag_busy_iter(). This BUG can be recreated by<br /> repeating the blktests test case nvme/063 a few times [1].<br /> <br /> When the BUG happens, nvme_tcp_create_ctrl() fails in the call chain<br /> below:<br /> <br /> nvme_tcp_create_ctrl()<br /> nvme_tcp_alloc_ctrl() new=true ... Alloc nvme_tcp_ctrl and admin_tag_set<br /> nvme_tcp_setup_ctrl() new=true<br /> nvme_tcp_configure_admin_queue() new=true ... Succeed<br /> nvme_alloc_admin_tag_set() ... Alloc the tag set for admin_tag_set<br /> nvme_stop_keep_alive()<br /> nvme_tcp_teardown_admin_queue() remove=false<br /> nvme_tcp_configure_admin_queue() new=false<br /> nvme_tcp_alloc_admin_queue() ... Fail, but do not call nvme_remove_admin_tag_set()<br /> nvme_uninit_ctrl()<br /> nvme_put_ctrl() ... Free up the nvme_tcp_ctrl and admin_tag_set<br /> <br /> The first call of nvme_tcp_configure_admin_queue() succeeds with<br /> new=true argument. The second call fails with new=false argument. This<br /> second call does not call nvme_remove_admin_tag_set() on failure, due to<br /> the new=false argument. Then the admin tag set is not removed. However,<br /> nvme_tcp_create_ctrl() assumes that nvme_tcp_setup_ctrl() would call<br /> nvme_remove_admin_tag_set(). Then it frees up struct nvme_tcp_ctrl which<br /> has admin_tag_set field. Later on, the timeout handler accesses the<br /> admin_tag_set field and causes the BUG KASAN slab-use-after-free.<br /> <br /> To not leave the admin tag set, call nvme_remove_admin_tag_set() when<br /> the second nvme_tcp_configure_admin_queue() call fails. Do not return<br /> from nvme_tcp_setup_ctrl() on failure. Instead, jump to "destroy_admin"<br /> go-to label to call nvme_tcp_teardown_admin_queue() which calls<br /> nvme_remove_admin_tag_set().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var<br /> <br /> If fb_add_videomode() in do_register_framebuffer() fails to allocate<br /> memory for fb_videomode, it will later lead to a null-ptr dereference in<br /> fb_videomode_to_var(), as the fb_info is registered while not having the<br /> mode in modelist that is expected to be there, i.e. the one that is<br /> described in fb_info-&gt;var.<br /> <br /> ================================================================<br /> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901<br /> Call Trace:<br /> display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929<br /> fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071<br /> resize_screen drivers/tty/vt/vt.c:1176 [inline]<br /> vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263<br /> fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720<br /> fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776<br /> do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128<br /> fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203<br /> vfs_ioctl fs/ioctl.c:48 [inline]<br /> __do_sys_ioctl fs/ioctl.c:753 [inline]<br /> __se_sys_ioctl fs/ioctl.c:739 [inline]<br /> __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739<br /> do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> ================================================================<br /> <br /> Even though fbcon_init() checks beforehand if fb_match_mode() in<br /> var_to_display() fails, it can not prevent the panic because fbcon_init()<br /> does not return error code. Considering this and the comment in the code<br /> about fb_match_mode() returning NULL - "This should not happen" - it is<br /> better to prevent registering the fb_info if its mode was not set<br /> successfully. Also move fb_add_videomode() closer to the beginning of<br /> do_register_framebuffer() to avoid having to do the cleanup on fail.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var<br /> <br /> If fb_add_videomode() in fb_set_var() fails to allocate memory for<br /> fb_videomode, later it may lead to a null-ptr dereference in<br /> fb_videomode_to_var(), as the fb_info is registered while not having the<br /> mode in modelist that is expected to be there, i.e. the one that is<br /> described in fb_info-&gt;var.<br /> <br /> ================================================================<br /> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901<br /> Call Trace:<br /> display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929<br /> fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071<br /> resize_screen drivers/tty/vt/vt.c:1176 [inline]<br /> vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263<br /> fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720<br /> fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776<br /> do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128<br /> fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203<br /> vfs_ioctl fs/ioctl.c:48 [inline]<br /> __do_sys_ioctl fs/ioctl.c:753 [inline]<br /> __se_sys_ioctl fs/ioctl.c:739 [inline]<br /> __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739<br /> do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> ================================================================<br /> <br /> The reason is that fb_info-&gt;var is being modified in fb_set_var(), and<br /> then fb_videomode_to_var() is called. If it fails to add the mode to<br /> fb_info-&gt;modelist, fb_set_var() returns error, but does not restore the<br /> old value of fb_info-&gt;var. Restore fb_info-&gt;var on failure the same way<br /> it is done earlier in the function.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc: fix to protect IPCS lookups using RCU<br /> <br /> syzbot reported that it discovered a use-after-free vulnerability, [0]<br /> <br /> [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/<br /> <br /> idr_for_each() is protected by rwsem, but this is not enough. If it is<br /> not protected by RCU read-critical region, when idr_for_each() calls<br /> radix_tree_node_free() through call_rcu() to free the radix_tree_node<br /> structure, the node will be freed immediately, and when reading the next<br /> node in radix_tree_for_each_slot(), the already freed memory may be read.<br /> <br /> Therefore, we need to add code to make sure that idr_for_each() is<br /> protected within the RCU read-critical region when we call it in<br /> shm_destroy_orphaned().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction<br /> <br /> The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last<br /> deref") simplified cm_id resource management by freeing cm_id once all<br /> references to the cm_id were removed. The references are removed either<br /> upon completion of iw_cm event handlers or when the application destroys<br /> the cm_id. This commit introduced the use-after-free condition where<br /> cm_id_private object could still be in use by event handler works during<br /> the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a<br /> use-after-free related to destroying CM IDs") addressed this use-after-<br /> free by flushing all pending works at the cm_id destruction.<br /> <br /> However, still another use-after-free possibility remained. It happens<br /> with the work objects allocated for each cm_id_priv within<br /> alloc_work_entries() during cm_id creation, and subsequently freed in<br /> dealloc_work_entries() once all references to the cm_id are removed.<br /> If the cm_id&amp;#39;s last reference is decremented in the event handler work,<br /> the work object for the work itself gets removed, and causes the use-<br /> after-free BUG below:<br /> <br /> BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250<br /> Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091<br /> <br /> CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014<br /> Workqueue: 0x0 (iw_cm_wq)<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6a/0x90<br /> print_report+0x174/0x554<br /> ? __virt_addr_valid+0x208/0x430<br /> ? __pwq_activate_work+0x1ff/0x250<br /> kasan_report+0xae/0x170<br /> ? __pwq_activate_work+0x1ff/0x250<br /> __pwq_activate_work+0x1ff/0x250<br /> pwq_dec_nr_in_flight+0x8c5/0xfb0<br /> process_one_work+0xc11/0x1460<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? assign_work+0x16c/0x240<br /> worker_thread+0x5ef/0xfd0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x3b0/0x770<br /> ? __pfx_kthread+0x10/0x10<br /> ? rcu_is_watching+0x11/0xb0<br /> ? _raw_spin_unlock_irq+0x24/0x50<br /> ? rcu_is_watching+0x11/0xb0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 147416:<br /> kasan_save_stack+0x2c/0x50<br /> kasan_save_track+0x10/0x30<br /> __kasan_kmalloc+0xa6/0xb0<br /> alloc_work_entries+0xa9/0x260 [iw_cm]<br /> iw_cm_connect+0x23/0x4a0 [iw_cm]<br /> rdma_connect_locked+0xbfd/0x1920 [rdma_cm]<br /> nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma]<br /> cma_cm_event_handler+0xae/0x320 [rdma_cm]<br /> cma_work_handler+0x106/0x1b0 [rdma_cm]<br /> process_one_work+0x84f/0x1460<br /> worker_thread+0x5ef/0xfd0<br /> kthread+0x3b0/0x770<br /> ret_from_fork+0x30/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 147091:<br /> kasan_save_stack+0x2c/0x50<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x37/0x60<br /> __kasan_slab_free+0x4b/0x70<br /> kfree+0x13a/0x4b0<br /> dealloc_work_entries+0x125/0x1f0 [iw_cm]<br /> iwcm_deref_id+0x6f/0xa0 [iw_cm]<br /> cm_work_handler+0x136/0x1ba0 [iw_cm]<br /> process_one_work+0x84f/0x1460<br /> worker_thread+0x5ef/0xfd0<br /> kthread+0x3b0/0x770<br /> ret_from_fork+0x30/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x2c/0x50<br /> kasan_record_aux_stack+0xa3/0xb0<br /> __queue_work+0x2ff/0x1390<br /> queue_work_on+0x67/0xc0<br /> cm_event_handler+0x46a/0x820 [iw_cm]<br /> siw_cm_upcall+0x330/0x650 [siw]<br /> siw_cm_work_handler+0x6b9/0x2b20 [siw]<br /> process_one_work+0x84f/0x1460<br /> worker_thread+0x5ef/0xfd0<br /> kthread+0x3b0/0x770<br /> ret_from_fork+0x30/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> This BUG is reproducible by repeating the blktests test case nvme/061<br /> for the rdma transport and the siw driver.<br /> <br /> To avoid the use-after-free of cm_id_private work objects, ensure that<br /> the last reference to the cm_id is decremented not in the event handler<br /> works, but in the cm_id destruction context. For that purpose, mo<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: add NULL check in automount_fullpath<br /> <br /> page is checked for null in __build_path_from_dentry_optional_prefix<br /> when tcon-&gt;origin_fullpath is not set. However, the check is missing when<br /> it is set.<br /> Add a check to prevent a potential NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix uprobe pte be overwritten when expanding vma<br /> <br /> Patch series "Fix uprobe pte be overwritten when expanding vma".<br /> <br /> <br /> This patch (of 4):<br /> <br /> We encountered a BUG alert triggered by Syzkaller as follows:<br /> BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1<br /> <br /> And we can reproduce it with the following steps:<br /> 1. register uprobe on file at zero offset<br /> 2. mmap the file at zero offset:<br /> addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);<br /> 3. mremap part of vma1 to new vma2:<br /> addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);<br /> 4. mremap back to orig addr1:<br /> mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);<br /> <br /> In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2<br /> with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1<br /> to vma2, then unmap the vma1 range [addr1, addr1 + 4096].<br /> <br /> In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the<br /> addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096,<br /> addr1 + 8192] still maps the file, it will take vma_merge_new_range to<br /> expand the range, and then do uprobe_mmap in vma_complete. Since the<br /> merged vma pgoff is also zero offset, it will install uprobe anon page to<br /> the merged vma. However, the upcomming move_page_tables step, which use<br /> set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite<br /> the newly uprobe pte in the merged vma, and lead that pte to be orphan.<br /> <br /> Since the uprobe pte will be remapped to the merged vma, we can remove the<br /> unnecessary uprobe_mmap upon merged vma.<br /> <br /> This problem was first found in linux-6.6.y and also exists in the<br /> community syzkaller:<br /> https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1<br /> <br /> [Why]<br /> If the dummy values in `populate_dummy_dml_surface_cfg()` aren&amp;#39;t updated<br /> then they can lead to a divide by zero in downstream callers like<br /> CalculateVMAndRowBytes()<br /> <br /> [How]<br /> Initialize dummy value to a value to avoid divide by zero.