Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> userfaultfd: fix checks for huge PMDs<br /> <br /> Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.<br /> <br /> The pmd_trans_huge() code in mfill_atomic() is wrong in three different<br /> ways depending on kernel version:<br /> <br /> 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit<br /> the right two race windows) - I&amp;#39;ve tested this in a kernel build with<br /> some extra mdelay() calls. See the commit message for a description<br /> of the race scenario.<br /> On older kernels (before 6.5), I think the same bug can even<br /> theoretically lead to accessing transhuge page contents as a page table<br /> if you hit the right 5 narrow race windows (I haven&amp;#39;t tested this case).<br /> 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for<br /> detecting PMDs that don&amp;#39;t point to page tables.<br /> On older kernels (before 6.5), you&amp;#39;d just have to win a single fairly<br /> wide race to hit this.<br /> I&amp;#39;ve tested this on 6.1 stable by racing migration (with a mdelay()<br /> patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86<br /> VM, that causes a kernel oops in ptlock_ptr().<br /> 3. On newer kernels (&gt;=6.5), for shmem mappings, khugepaged is allowed<br /> to yank page tables out from under us (though I haven&amp;#39;t tested that),<br /> so I think the BUG_ON() checks in mfill_atomic() are just wrong.<br /> <br /> I decided to write two separate fixes for these (one fix for bugs 1+2, one<br /> fix for bug 3), so that the first fix can be backported to kernels<br /> affected by bugs 1+2.<br /> <br /> <br /> This patch (of 2):<br /> <br /> This fixes two issues.<br /> <br /> I discovered that the following race can occur:<br /> <br /> mfill_atomic other thread<br /> ============ ============<br /> <br /> pmdp_get_lockless() [reads none pmd]<br /> <br /> <br /> <br /> __pte_alloc [no-op]<br /> <br /> <br /> BUG_ON(pmd_none(*dst_pmd))<br /> <br /> I have experimentally verified this in a kernel with extra mdelay() calls;<br /> the BUG_ON(pmd_none(*dst_pmd)) triggers.<br /> <br /> On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow<br /> pte_offset_map[_lock]() to fail"), this can&amp;#39;t lead to anything worse than<br /> a BUG_ON(), since the page table access helpers are actually designed to<br /> deal with page tables concurrently disappearing; but on older kernels<br /> (

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/osnoise: Use a cpumask to know what threads are kthreads<br /> <br /> The start_kthread() and stop_thread() code was not always called with the<br /> interface_lock held. This means that the kthread variable could be<br /> unexpectedly changed causing the kthread_stop() to be called on it when it<br /> should not have been, leading to:<br /> <br /> while true; do<br /> rtla timerlat top -u -q &amp; PID=$!;<br /> sleep 5;<br /> kill -INT $PID;<br /> sleep 0.001;<br /> kill -TERM $PID;<br /> wait $PID;<br /> done<br /> <br /> Causing the following OOPS:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:hrtimer_active+0x58/0x300<br /> Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f<br /> RSP: 0018:ffff88811d97f940 EFLAGS: 00010202<br /> RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b<br /> RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28<br /> RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60<br /> R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d<br /> R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28<br /> FS: 0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0<br /> Call Trace:<br /> <br /> ? die_addr+0x40/0xa0<br /> ? exc_general_protection+0x154/0x230<br /> ? asm_exc_general_protection+0x26/0x30<br /> ? hrtimer_active+0x58/0x300<br /> ? __pfx_mutex_lock+0x10/0x10<br /> ? __pfx_locks_remove_file+0x10/0x10<br /> hrtimer_cancel+0x15/0x40<br /> timerlat_fd_release+0x8e/0x1f0<br /> ? security_file_release+0x43/0x80<br /> __fput+0x372/0xb10<br /> task_work_run+0x11e/0x1f0<br /> ? _raw_spin_lock+0x85/0xe0<br /> ? __pfx_task_work_run+0x10/0x10<br /> ? poison_slab_object+0x109/0x170<br /> ? do_exit+0x7a0/0x24b0<br /> do_exit+0x7bd/0x24b0<br /> ? __pfx_migrate_enable+0x10/0x10<br /> ? __pfx_do_exit+0x10/0x10<br /> ? __pfx_read_tsc+0x10/0x10<br /> ? ktime_get+0x64/0x140<br /> ? _raw_spin_lock_irq+0x86/0xe0<br /> do_group_exit+0xb0/0x220<br /> get_signal+0x17ba/0x1b50<br /> ? vfs_read+0x179/0xa40<br /> ? timerlat_fd_read+0x30b/0x9d0<br /> ? __pfx_get_signal+0x10/0x10<br /> ? __pfx_timerlat_fd_read+0x10/0x10<br /> arch_do_signal_or_restart+0x8c/0x570<br /> ? __pfx_arch_do_signal_or_restart+0x10/0x10<br /> ? vfs_read+0x179/0xa40<br /> ? ksys_read+0xfe/0x1d0<br /> ? __pfx_ksys_read+0x10/0x10<br /> syscall_exit_to_user_mode+0xbc/0x130<br /> do_syscall_64+0x74/0x110<br /> ? __pfx___rseq_handle_notify_resume+0x10/0x10<br /> ? __pfx_ksys_read+0x10/0x10<br /> ? fpregs_restore_userregs+0xdb/0x1e0<br /> ? fpregs_restore_userregs+0xdb/0x1e0<br /> ? syscall_exit_to_user_mode+0x116/0x130<br /> ? do_syscall_64+0x74/0x110<br /> ? do_syscall_64+0x74/0x110<br /> ? do_syscall_64+0x74/0x110<br /> entry_SYSCALL_64_after_hwframe+0x71/0x79<br /> RIP: 0033:0x7ff0070eca9c<br /> Code: Unable to access opcode bytes at 0x7ff0070eca72.<br /> RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c<br /> RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003<br /> RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0<br /> R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003<br /> R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008<br /> <br /> Modules linked in: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This is because it would mistakenly call kthread_stop() on a user space<br /> thread making it "exit" before it actually exits.<br /> <br /> Since kthread<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: add check for s-&gt;flags in the alloc_tagging_slab_free_hook<br /> <br /> When enable CONFIG_MEMCG &amp; CONFIG_KFENCE &amp; CONFIG_KMEMLEAK, the following<br /> warning always occurs,This is because the following call stack occurred:<br /> mem_pool_alloc<br /> kmem_cache_alloc_noprof<br /> slab_alloc_node<br /> kfence_alloc<br /> <br /> Once the kfence allocation is successful,slab-&gt;obj_exts will not be empty,<br /> because it has already been assigned a value in kfence_init_pool.<br /> <br /> Since in the prepare_slab_obj_exts_hook function,we perform a check for<br /> s-&gt;flags &amp; (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE),the alloc_tag_add function<br /> will not be called as a result.Therefore,ref-&gt;ct remains NULL.<br /> <br /> However,when we call mem_pool_free,since obj_ext is not empty, it<br /> eventually leads to the alloc_tag_sub scenario being invoked. This is<br /> where the warning occurs.<br /> <br /> So we should add corresponding checks in the alloc_tagging_slab_free_hook.<br /> For __GFP_NO_OBJ_EXT case,I didn&amp;#39;t see the specific case where it&amp;#39;s using<br /> kfence,so I won&amp;#39;t add the corresponding check in<br /> alloc_tagging_slab_free_hook for now.<br /> <br /> [ 3.734349] ------------[ cut here ]------------<br /> [ 3.734807] alloc_tag was not set<br /> [ 3.735129] WARNING: CPU: 4 PID: 40 at ./include/linux/alloc_tag.h:130 kmem_cache_free+0x444/0x574<br /> [ 3.735866] Modules linked in: autofs4<br /> [ 3.736211] CPU: 4 UID: 0 PID: 40 Comm: ksoftirqd/4 Tainted: G W 6.11.0-rc3-dirty #1<br /> [ 3.736969] Tainted: [W]=WARN<br /> [ 3.737258] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022<br /> [ 3.737875] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 3.738501] pc : kmem_cache_free+0x444/0x574<br /> [ 3.738951] lr : kmem_cache_free+0x444/0x574<br /> [ 3.739361] sp : ffff80008357bb60<br /> [ 3.739693] x29: ffff80008357bb70 x28: 0000000000000000 x27: 0000000000000000<br /> [ 3.740338] x26: ffff80008207f000 x25: ffff000b2eb2fd60 x24: ffff0000c0005700<br /> [ 3.740982] x23: ffff8000804229e4 x22: ffff800082080000 x21: ffff800081756000<br /> [ 3.741630] x20: fffffd7ff8253360 x19: 00000000000000a8 x18: ffffffffffffffff<br /> [ 3.742274] x17: ffff800ab327f000 x16: ffff800083398000 x15: ffff800081756df0<br /> [ 3.742919] x14: 0000000000000000 x13: 205d344320202020 x12: 5b5d373038343337<br /> [ 3.743560] x11: ffff80008357b650 x10: 000000000000005d x9 : 00000000ffffffd0<br /> [ 3.744231] x8 : 7f7f7f7f7f7f7f7f x7 : ffff80008237bad0 x6 : c0000000ffff7fff<br /> [ 3.744907] x5 : ffff80008237ba78 x4 : ffff8000820bbad0 x3 : 0000000000000001<br /> [ 3.745580] x2 : 68d66547c09f7800 x1 : 68d66547c09f7800 x0 : 0000000000000000<br /> [ 3.746255] Call trace:<br /> [ 3.746530] kmem_cache_free+0x444/0x574<br /> [ 3.746931] mem_pool_free+0x44/0xf4<br /> [ 3.747306] free_object_rcu+0xc8/0xdc<br /> [ 3.747693] rcu_do_batch+0x234/0x8a4<br /> [ 3.748075] rcu_core+0x230/0x3e4<br /> [ 3.748424] rcu_core_si+0x14/0x1c<br /> [ 3.748780] handle_softirqs+0x134/0x378<br /> [ 3.749189] run_ksoftirqd+0x70/0x9c<br /> [ 3.749560] smpboot_thread_fn+0x148/0x22c<br /> [ 3.749978] kthread+0x10c/0x118<br /> [ 3.750323] ret_from_fork+0x10/0x20<br /> [ 3.750696] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check denominator crb_pipes before used<br /> <br /> [WHAT &amp; HOW]<br /> A denominator cannot be 0, and is checked before used.<br /> <br /> This fixes 2 DIVIDE_BY_ZERO issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas()<br /> <br /> Smatch warns:<br /> <br /> arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential<br /> spectre issue &amp;#39;args.args&amp;#39; [r] (local cap)<br /> <br /> The &amp;#39;nargs&amp;#39; and &amp;#39;nret&amp;#39; locals come directly from a user-supplied<br /> buffer and are used as indexes into a small stack-based array and as<br /> inputs to copy_to_user() after they are subject to bounds checks.<br /> <br /> Use array_index_nospec() after the bounds checks to clamp these values<br /> for speculative execution.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: bcm: Remove proc entry when dev is unregistered.<br /> <br /> syzkaller reported a warning in bcm_connect() below. [0]<br /> <br /> The repro calls connect() to vxcan1, removes vxcan1, and calls<br /> connect() with ifindex == 0.<br /> <br /> Calling connect() for a BCM socket allocates a proc entry.<br /> Then, bcm_sk(sk)-&gt;bound is set to 1 to prevent further connect().<br /> <br /> However, removing the bound device resets bcm_sk(sk)-&gt;bound to 0<br /> in bcm_notify().<br /> <br /> The 2nd connect() tries to allocate a proc entry with the same<br /> name and sets NULL to bcm_sk(sk)-&gt;bcm_proc_read, leaking the<br /> original proc entry.<br /> <br /> Since the proc entry is available only for connect()ed sockets,<br /> let&amp;#39;s clean up the entry when the bound netdev is unregistered.<br /> <br /> [0]:<br /> proc_dir_entry &amp;#39;can-bcm/2456&amp;#39; already registered<br /> WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375<br /> Modules linked in:<br /> CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375<br /> Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48<br /> RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246<br /> RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002<br /> RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0<br /> R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec<br /> FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220<br /> bcm_connect+0x472/0x840 net/can/bcm.c:1673<br /> __sys_connect_file net/socket.c:2049 [inline]<br /> __sys_connect+0x5d2/0x690 net/socket.c:2066<br /> __do_sys_connect net/socket.c:2076 [inline]<br /> __se_sys_connect net/socket.c:2073 [inline]<br /> __x64_sys_connect+0x8f/0x100 net/socket.c:2073<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7fbd708b0e5d<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d<br /> RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040<br /> R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098<br /> R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000<br /> <br /> remove_proc_entry: removing non-empty directory &amp;#39;net/can-bcm&amp;#39;, leaking at least &amp;#39;2456&amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check denominator pbn_div before used<br /> <br /> [WHAT &amp; HOW]<br /> A denominator cannot be 0, and is checked before used.<br /> <br /> This fixes 1 DIVIDE_BY_ZERO issue reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Avoid excessive partition lengths<br /> <br /> Avoid mounting filesystems where the partition would overflow the<br /> 32-bits used for block number. Also refuse to mount filesystems where<br /> the partition length is so large we cannot safely index bits in a<br /> block bitmap.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: protect references to superblock parameters exposed in sysfs<br /> <br /> The superblock buffers of nilfs2 can not only be overwritten at runtime<br /> for modifications/repairs, but they are also regularly swapped, replaced<br /> during resizing, and even abandoned when degrading to one side due to<br /> backing device issues. So, accessing them requires mutual exclusion using<br /> the reader/writer semaphore "nilfs-&gt;ns_sem".<br /> <br /> Some sysfs attribute show methods read this superblock buffer without the<br /> necessary mutual exclusion, which can cause problems with pointer<br /> dereferencing and memory access, so fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix missing cleanup on rollforward recovery error<br /> <br /> In an error injection test of a routine for mount-time recovery, KASAN<br /> found a use-after-free bug.<br /> <br /> It turned out that if data recovery was performed using partial logs<br /> created by dsync writes, but an error occurred before starting the log<br /> writer to create a recovered checkpoint, the inodes whose data had been<br /> recovered were left in the ns_dirty_files list of the nilfs object and<br /> were not freed.<br /> <br /> Fix this issue by cleaning up inodes that have read the recovery data if<br /> the recovery routine fails midway before the log writer starts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ila: call nf_unregister_net_hooks() sooner<br /> <br /> syzbot found an use-after-free Read in ila_nf_input [1]<br /> <br /> Issue here is that ila_xlat_exit_net() frees the rhashtable,<br /> then call nf_unregister_net_hooks().<br /> <br /> It should be done in the reverse way, with a synchronize_rcu().<br /> <br /> This is a good match for a pre_exit() method.<br /> <br /> [1]<br /> BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]<br /> BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]<br /> BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]<br /> BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672<br /> Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16<br /> <br /> CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> rht_key_hashfn include/linux/rhashtable.h:159 [inline]<br /> __rhashtable_lookup include/linux/rhashtable.h:604 [inline]<br /> rhashtable_lookup include/linux/rhashtable.h:646 [inline]<br /> rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672<br /> ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]<br /> ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]<br /> ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626<br /> nf_hook include/linux/netfilter.h:269 [inline]<br /> NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312<br /> __netif_receive_skb_one_core net/core/dev.c:5661 [inline]<br /> __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775<br /> process_backlog+0x662/0x15b0 net/core/dev.c:6108<br /> __napi_poll+0xcb/0x490 net/core/dev.c:6772<br /> napi_poll net/core/dev.c:6841 [inline]<br /> net_rx_action+0x89b/0x1240 net/core/dev.c:6963<br /> handle_softirqs+0x2c4/0x970 kernel/softirq.c:554<br /> run_ksoftirqd+0xca/0x130 kernel/softirq.c:928<br /> smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620<br /> flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)<br /> page_type: 0xbfffffff(buddy)<br /> raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000<br /> raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as freed<br /> page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187<br /> set_page_owner include/linux/page_owner.h:32 [inline]<br /> post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493<br /> prep_new_page mm/page_alloc.c:1501 [inline]<br /> get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439<br /> __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695<br /> __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]<br /> alloc_pages_node_noprof include/linux/gfp.h:296 [inline]<br /> ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103<br /> __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130<br /> __do_kmalloc_node mm/slub.c:4146 [inline]<br /> __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164<br /> __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650<br /> bucket_table_alloc lib/rhashtable.c:186 [inline]<br /> rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071<br /> ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613<br /> ops_ini<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_bpf: fix return value of tcp_bpf_sendmsg()<br /> <br /> When we cork messages in psock-&gt;cork, the last message triggers the<br /> flushing will result in sending a sk_msg larger than the current<br /> message size. In this case, in tcp_bpf_send_verdict(), &amp;#39;copied&amp;#39; becomes<br /> negative at least in the following case:<br /> <br /> 468 case __SK_DROP:<br /> 469 default:<br /> 470 sk_msg_free_partial(sk, msg, tosend);<br /> 471 sk_msg_apply_bytes(psock, tosend);<br /> 472 *copied -= (tosend + delta); //