Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: Avoid blocking in RCU read-side critical section<br /> <br /> A panic happens in ima_match_policy:<br /> <br /> BUG: unable to handle kernel NULL pointer dereference at 0000000000000010<br /> PGD 42f873067 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 5 PID: 1286325 Comm: kubeletmonit.sh<br /> Kdump: loaded Tainted: P<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> BIOS 0.0.0 02/06/2015<br /> RIP: 0010:ima_match_policy+0x84/0x450<br /> Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39<br /> 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d<br /> f2 b9 f4 00 0f 84 9c 01 00 00 85 73 10 74 ea<br /> 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f<br /> RSP: 0018:ff71570009e07a80 EFLAGS: 00010207<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200<br /> RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739<br /> R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970<br /> R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001<br /> FS: 00007f5195b51740(0000)<br /> GS:ff3e278b12d40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ima_get_action+0x22/0x30<br /> process_measurement+0xb0/0x830<br /> ? page_add_file_rmap+0x15/0x170<br /> ? alloc_set_pte+0x269/0x4c0<br /> ? prep_new_page+0x81/0x140<br /> ? simple_xattr_get+0x75/0xa0<br /> ? selinux_file_open+0x9d/0xf0<br /> ima_file_check+0x64/0x90<br /> path_openat+0x571/0x1720<br /> do_filp_open+0x9b/0x110<br /> ? page_counter_try_charge+0x57/0xc0<br /> ? files_cgroup_alloc_fd+0x38/0x60<br /> ? __alloc_fd+0xd4/0x250<br /> ? do_sys_open+0x1bd/0x250<br /> do_sys_open+0x1bd/0x250<br /> do_syscall_64+0x5d/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by<br /> ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a<br /> RCU read-side critical section which contains kmalloc with GFP_KERNEL.<br /> This implies a possible sleep and violates limitations of RCU read-side<br /> critical sections on non-PREEMPT systems.<br /> <br /> Sleeping within RCU read-side critical section might cause<br /> synchronize_rcu() returning early and break RCU protection, allowing a<br /> UAF to happen.<br /> <br /> The root cause of this issue could be described as follows:<br /> | Thread A | Thread B |<br /> | |ima_match_policy |<br /> | | rcu_read_lock |<br /> |ima_lsm_update_rule | |<br /> | synchronize_rcu | |<br /> | | kmalloc(GFP_KERNEL)|<br /> | | sleep |<br /> ==&gt; synchronize_rcu returns early<br /> | kfree(entry) | |<br /> | | entry = entry-&gt;next|<br /> ==&gt; UAF happens and entry now becomes NULL (or could be anything).<br /> | | entry-&gt;action |<br /> ==&gt; Accessing entry might cause panic.<br /> <br /> To fix this issue, we are converting all kmalloc that is called within<br /> RCU read-side critical section to use GFP_ATOMIC.<br /> <br /> [PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: shmem: fix getting incorrect lruvec when replacing a shmem folio<br /> <br /> When testing shmem swapin, I encountered the warning below on my machine. <br /> The reason is that replacing an old shmem folio with a new one causes<br /> mem_cgroup_migrate() to clear the old folio&amp;#39;s memcg data. As a result,<br /> the old folio cannot get the correct memcg&amp;#39;s lruvec needed to remove<br /> itself from the LRU list when it is being freed. This could lead to<br /> possible serious problems, such as LRU list crashes due to holding the<br /> wrong LRU lock, and incorrect LRU statistics.<br /> <br /> To fix this issue, we can fallback to use the mem_cgroup_replace_folio()<br /> to replace the old shmem folio.<br /> <br /> [ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960<br /> [ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> [ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff)<br /> [ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000<br /> [ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000<br /> [ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000<br /> [ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg &amp;&amp; !mem_cgroup_disabled())<br /> [ 5241.100338] ------------[ cut here ]------------<br /> [ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150<br /> [...]<br /> [ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150<br /> [ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150<br /> [ 5241.100376] sp : ffff80008b38b930<br /> [...]<br /> [ 5241.100398] Call trace:<br /> [ 5241.100399] folio_lruvec_lock_irqsave+0x140/0x150<br /> [ 5241.100401] __page_cache_release+0x90/0x300<br /> [ 5241.100404] __folio_put+0x50/0x108<br /> [ 5241.100406] shmem_replace_folio+0x1b4/0x240<br /> [ 5241.100409] shmem_swapin_folio+0x314/0x528<br /> [ 5241.100411] shmem_get_folio_gfp+0x3b4/0x930<br /> [ 5241.100412] shmem_fault+0x74/0x160<br /> [ 5241.100414] __do_fault+0x40/0x218<br /> [ 5241.100417] do_shared_fault+0x34/0x1b0<br /> [ 5241.100419] do_fault+0x40/0x168<br /> [ 5241.100420] handle_pte_fault+0x80/0x228<br /> [ 5241.100422] __handle_mm_fault+0x1c4/0x440<br /> [ 5241.100424] handle_mm_fault+0x60/0x1f0<br /> [ 5241.100426] do_page_fault+0x120/0x488<br /> [ 5241.100429] do_translation_fault+0x4c/0x68<br /> [ 5241.100431] do_mem_abort+0x48/0xa0<br /> [ 5241.100434] el0_da+0x38/0xc0<br /> [ 5241.100436] el0t_64_sync_handler+0x68/0xc0<br /> [ 5241.100437] el0t_64_sync+0x14c/0x150<br /> [ 5241.100439] ---[ end trace 0000000000000000 ]---<br /> <br /> [baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()<br /> <br /> Use {READ,WRITE}_ONCE() to access kvm-&gt;last_boosted_vcpu to ensure the<br /> loads and stores are atomic. In the extremely unlikely scenario the<br /> compiler tears the stores, it&amp;#39;s theoretically possible for KVM to attempt<br /> to get a vCPU using an out-of-bounds index, e.g. if the write is split<br /> into multiple 8-bit stores, and is paired with a 32-bit load on a VM with<br /> 257 vCPUs:<br /> <br /> CPU0 CPU1<br /> last_boosted_vcpu = 0xff;<br /> <br /> (last_boosted_vcpu = 0x100)<br /> last_boosted_vcpu[15:8] = 0x01;<br /> i = (last_boosted_vcpu = 0x1ff)<br /> last_boosted_vcpu[7:0] = 0x00;<br /> <br /> vcpu = kvm-&gt;vcpu_array[0x1ff];<br /> <br /> As detected by KCSAN:<br /> <br /> BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]<br /> <br /> write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:<br /> kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm<br /> handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel<br /> vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?<br /> arch/x86/kvm/vmx/vmx.c:6606) kvm_intel<br /> vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm<br /> kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm<br /> kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm<br /> __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)<br /> __x64_sys_ioctl (fs/ioctl.c:890)<br /> x64_sys_call (arch/x86/entry/syscall_64.c:33)<br /> do_syscall_64 (arch/x86/entry/common.c:?)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:<br /> kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm<br /> handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel<br /> vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?<br /> arch/x86/kvm/vmx/vmx.c:6606) kvm_intel<br /> vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm<br /> kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm<br /> kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm<br /> __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)<br /> __x64_sys_ioctl (fs/ioctl.c:890)<br /> x64_sys_call (arch/x86/entry/syscall_64.c:33)<br /> do_syscall_64 (arch/x86/entry/common.c:?)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> value changed: 0x00000012 -&gt; 0x00000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: do not leave a dangling sk pointer, when socket creation fails<br /> <br /> It is possible to trigger a use-after-free by:<br /> * attaching an fentry probe to __sock_release() and the probe calling the<br /> bpf_get_socket_cookie() helper<br /> * running traceroute -I 1.1.1.1 on a freshly booted VM<br /> <br /> A KASAN enabled kernel will log something like below (decoded and stripped):<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)<br /> Read of size 8 at addr ffff888007110dd8 by task traceroute/299<br /> <br /> CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))<br /> print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)<br /> ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)<br /> kasan_report (mm/kasan/report.c:603)<br /> ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)<br /> kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189)<br /> __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)<br /> bpf_get_socket_ptr_cookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092)<br /> bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e<br /> bpf_trampoline_6442506592+0x47/0xaf<br /> __sock_release (net/socket.c:652)<br /> __sock_create (net/socket.c:1601)<br /> ...<br /> Allocated by task 299 on cpu 2 at 78.328492s:<br /> kasan_save_stack (mm/kasan/common.c:48)<br /> kasan_save_track (mm/kasan/common.c:68)<br /> __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338)<br /> kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007)<br /> sk_prot_alloc (net/core/sock.c:2075)<br /> sk_alloc (net/core/sock.c:2134)<br /> inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252)<br /> __sock_create (net/socket.c:1572)<br /> __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)<br /> __x64_sys_socket (net/socket.c:1718)<br /> do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> Freed by task 299 on cpu 2 at 78.328502s:<br /> kasan_save_stack (mm/kasan/common.c:48)<br /> kasan_save_track (mm/kasan/common.c:68)<br /> kasan_save_free_info (mm/kasan/generic.c:582)<br /> poison_slab_object (mm/kasan/common.c:242)<br /> __kasan_slab_free (mm/kasan/common.c:256)<br /> kmem_cache_free (mm/slub.c:4437 mm/slub.c:4511)<br /> __sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208)<br /> inet_create (net/ipv4/af_inet.c:397 net/ipv4/af_inet.c:252)<br /> __sock_create (net/socket.c:1572)<br /> __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)<br /> __x64_sys_socket (net/socket.c:1718)<br /> do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> Fix this by clearing the struct socket reference in sk_common_release() to cover<br /> all protocol families create functions, which may already attached the<br /> reference to the sk object with sock_init_data().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list<br /> <br /> Use list_for_each_entry_safe() to allow iterating through the list and<br /> deleting the entry in the iteration process. The descriptor is freed via<br /> idxd_desc_complete() and there&amp;#39;s a slight chance may cause issue for<br /> the list iterator when the descriptor is reused by another thread<br /> without it being deleted from the list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors<br /> <br /> input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for<br /> PREROUTING hook, in PREROUTING hook, we should passing a valid indev,<br /> and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer<br /> dereference, as below:<br /> <br /> [74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090<br /> [74830.655633] #PF: supervisor read access in kernel mode<br /> [74830.657888] #PF: error_code(0x0000) - not-present page<br /> [74830.659500] PGD 0 P4D 0<br /> [74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI<br /> ...<br /> [74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011<br /> [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter]<br /> ...<br /> [74830.689725] Call Trace:<br /> [74830.690402] <br /> [74830.690953] ? show_trace_log_lvl+0x1c4/0x2df<br /> [74830.692020] ? show_trace_log_lvl+0x1c4/0x2df<br /> [74830.693095] ? ipt_do_table+0x286/0x710 [ip_tables]<br /> [74830.694275] ? __die_body.cold+0x8/0xd<br /> [74830.695205] ? page_fault_oops+0xac/0x140<br /> [74830.696244] ? exc_page_fault+0x62/0x150<br /> [74830.697225] ? asm_exc_page_fault+0x22/0x30<br /> [74830.698344] ? rpfilter_mt+0x44/0x15e [ipt_rpfilter]<br /> [74830.699540] ipt_do_table+0x286/0x710 [ip_tables]<br /> [74830.700758] ? ip6_route_input+0x19d/0x240<br /> [74830.701752] nf_hook_slow+0x3f/0xb0<br /> [74830.702678] input_action_end_dx4+0x19b/0x1e0<br /> [74830.703735] ? input_action_end_t+0xe0/0xe0<br /> [74830.704734] seg6_local_input_core+0x2d/0x60<br /> [74830.705782] lwtunnel_input+0x5b/0xb0<br /> [74830.706690] __netif_receive_skb_one_core+0x63/0xa0<br /> [74830.707825] process_backlog+0x99/0x140<br /> [74830.709538] __napi_poll+0x2c/0x160<br /> [74830.710673] net_rx_action+0x296/0x350<br /> [74830.711860] __do_softirq+0xcb/0x2ac<br /> [74830.713049] do_softirq+0x63/0x90<br /> <br /> input_action_end_dx4() passing a NULL indev to NF_HOOK(), and finally<br /> trigger a NULL dereference in rpfilter_mt()-&gt;rpfilter_is_loopback():<br /> <br /> static bool<br /> rpfilter_is_loopback(const struct sk_buff *skb,<br /> const struct net_device *in)<br /> {<br /> // in is NULL<br /> return skb-&gt;pkt_type == PACKET_LOOPBACK ||<br /> in-&gt;flags &amp; IFF_LOOPBACK;<br /> }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netns: Make get_net_ns() handle zero refcount net<br /> <br /> Syzkaller hit a warning:<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0<br /> Modules linked in:<br /> CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0xdf/0x1d0<br /> Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1<br /> RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac<br /> RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001<br /> RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139<br /> R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4<br /> R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040<br /> FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? show_regs+0xa3/0xc0<br /> ? __warn+0xa5/0x1c0<br /> ? refcount_warn_saturate+0xdf/0x1d0<br /> ? report_bug+0x1fc/0x2d0<br /> ? refcount_warn_saturate+0xdf/0x1d0<br /> ? handle_bug+0xa1/0x110<br /> ? exc_invalid_op+0x3c/0xb0<br /> ? asm_exc_invalid_op+0x1f/0x30<br /> ? __warn_printk+0xcc/0x140<br /> ? __warn_printk+0xd5/0x140<br /> ? refcount_warn_saturate+0xdf/0x1d0<br /> get_net_ns+0xa4/0xc0<br /> ? __pfx_get_net_ns+0x10/0x10<br /> open_related_ns+0x5a/0x130<br /> __tun_chr_ioctl+0x1616/0x2370<br /> ? __sanitizer_cov_trace_switch+0x58/0xa0<br /> ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30<br /> ? __pfx_tun_chr_ioctl+0x10/0x10<br /> tun_chr_ioctl+0x2f/0x40<br /> __x64_sys_ioctl+0x11b/0x160<br /> x64_sys_call+0x1211/0x20d0<br /> do_syscall_64+0x9e/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f5b28f165d7<br /> Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8<br /> RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7<br /> RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003<br /> RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0<br /> R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730<br /> R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> Kernel panic - not syncing: kernel: panic_on_warn set ...<br /> <br /> This is trigger as below:<br /> ns0 ns1<br /> tun_set_iff() //dev is tun0<br /> tun-&gt;dev = dev<br /> //ip link set tun0 netns ns1<br /> put_net() //ref is 0<br /> __tun_chr_ioctl() //TUNGETDEVNETNS<br /> net = dev_net(tun-&gt;dev);<br /> open_related_ns(&amp;net-&gt;ns, get_net_ns); //ns1<br /> get_net_ns()<br /> get_net() //addition on 0<br /> <br /> Use maybe_get_net() in get_net_ns in case net&amp;#39;s ref is zero to fix this

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: flush all requests after setting CACHEFILES_DEAD<br /> <br /> In ondemand mode, when the daemon is processing an open request, if the<br /> kernel flags the cache as CACHEFILES_DEAD, the cachefiles_daemon_write()<br /> will always return -EIO, so the daemon can&amp;#39;t pass the copen to the kernel.<br /> Then the kernel process that is waiting for the copen triggers a hung_task.<br /> <br /> Since the DEAD state is irreversible, it can only be exited by closing<br /> /dev/cachefiles. Therefore, after calling cachefiles_io_error() to mark<br /> the cache as CACHEFILES_DEAD, if in ondemand mode, flush all requests to<br /> avoid the above hungtask. We may still be able to read some of the cached<br /> data before closing the fd of /dev/cachefiles.<br /> <br /> Note that this relies on the patch that adds reference counting to the req,<br /> otherwise it may UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/region: Fix memregion leaks in devm_cxl_add_region()<br /> <br /> Move the mode verification to __create_region() before allocating the<br /> memregion to avoid the memregion leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> landlock: Fix d_parent walk<br /> <br /> The WARN_ON_ONCE() in collect_domain_accesses() can be triggered when<br /> trying to link a root mount point. This cannot work in practice because<br /> this directory is mounted, but the VFS check is done after the call to<br /> security_path_link().<br /> <br /> Do not use source directory&amp;#39;s d_parent when the source directory is the<br /> mount point.<br /> <br /> [mic: Fix commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: iosm: Fix tainted pointer delete is case of region creation fail<br /> <br /> In case of region creation fail in ipc_devlink_create_region(), previously<br /> created regions delete process starts from tainted pointer which actually<br /> holds error code value.<br /> Fix this bug by decreasing region index before delete.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix tainted pointer delete is case of flow rules creation fail<br /> <br /> In case of flow rule creation fail in mlx5_lag_create_port_sel_table(),<br /> instead of previously created rules, the tainted pointer is deleted<br /> deveral times.<br /> Fix this bug by using correct flow rules pointers.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.