Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: add more sanity checks to qdisc_pkt_len_init()<br /> <br /> One path takes care of SKB_GSO_DODGY, assuming<br /> skb-&gt;len is bigger than hdr_len.<br /> <br /> virtio_net_hdr_to_skb() does not fully dissect TCP headers,<br /> it only make sure it is at least 20 bytes.<br /> <br /> It is possible for an user to provide a malicious &amp;#39;GSO&amp;#39; packet,<br /> total length of 80 bytes.<br /> <br /> - 20 bytes of IPv4 header<br /> - 60 bytes TCP header<br /> - a small gso_size like 8<br /> <br /> virtio_net_hdr_to_skb() would declare this packet as a normal<br /> GSO packet, because it would see 40 bytes of payload,<br /> bigger than gso_size.<br /> <br /> We need to make detect this case to not underflow<br /> qdisc_skb_cb(skb)-&gt;pkt_len.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: avoid potential underflow in qdisc_pkt_len_init() with UFO<br /> <br /> After commit 7c6d2ecbda83 ("net: be more gentle about silly gso<br /> requests coming from user") virtio_net_hdr_to_skb() had sanity check<br /> to detect malicious attempts from user space to cook a bad GSO packet.<br /> <br /> Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count<br /> transport header in UFO") while fixing one issue, allowed user space<br /> to cook a GSO packet with the following characteristic :<br /> <br /> IPv4 SKB_GSO_UDP, gso_size=3, skb-&gt;len = 28.<br /> <br /> When this packet arrives in qdisc_pkt_len_init(), we end up<br /> with hdr_len = 28 (IPv4 header + UDP header), matching skb-&gt;len<br /> <br /> Then the following sets gso_segs to 0 :<br /> <br /> gso_segs = DIV_ROUND_UP(skb-&gt;len - hdr_len,<br /> shinfo-&gt;gso_size);<br /> <br /> Then later we set qdisc_skb_cb(skb)-&gt;pkt_len to back to zero :/<br /> <br /> qdisc_skb_cb(skb)-&gt;pkt_len += (gso_segs - 1) * hdr_len;<br /> <br /> This leads to the following crash in fq_codel [1]<br /> <br /> qdisc_pkt_len_init() is best effort, we only want an estimation<br /> of the bytes sent on the wire, not crashing the kernel.<br /> <br /> This patch is fixing this particular issue, a following one<br /> adds more sanity checks for another potential bug.<br /> <br /> [1]<br /> [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 70.724561] #PF: supervisor read access in kernel mode<br /> [ 70.724561] #PF: error_code(0x0000) - not-present page<br /> [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0<br /> [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991<br /> [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel<br /> [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49<br /> All code<br /> ========<br /> 0: 24 08 and $0x8,%al<br /> 2: 49 c1 e1 06 shl $0x6,%r9<br /> 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp)<br /> b: 45 31 ed xor %r13d,%r13d<br /> e: 45 31 c0 xor %r8d,%r8d<br /> 11: 31 ff xor %edi,%edi<br /> 13: 89 44 24 14 mov %eax,0x14(%rsp)<br /> 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9<br /> 1e: eb 04 jmp 0x24<br /> 20: 39 ca cmp %ecx,%edx<br /> 22: 73 37 jae 0x5b<br /> 24: 4d 8b 39 mov (%r9),%r15<br /> 27: 83 c7 01 add $0x1,%edi<br /> 2a:* 49 8b 17 mov (%r15),%rdx

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix uaf in l2cap_connect<br /> <br /> [Syzbot reported]<br /> BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949<br /> Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54<br /> <br /> CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Workqueue: hci2 hci_rx_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc3/0x620 mm/kasan/report.c:488<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:601<br /> l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949<br /> l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]<br /> l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]<br /> l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]<br /> l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825<br /> l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514<br /> hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]<br /> hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028<br /> process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231<br /> process_scheduled_works kernel/workqueue.c:3312 [inline]<br /> worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389<br /> kthread+0x2c1/0x3a0 kernel/kthread.c:389<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> ...<br /> <br /> Freed by task 5245:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579<br /> poison_slab_object+0xf7/0x160 mm/kasan/common.c:240<br /> __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256<br /> kasan_slab_free include/linux/kasan.h:184 [inline]<br /> slab_free_hook mm/slub.c:2256 [inline]<br /> slab_free mm/slub.c:4477 [inline]<br /> kfree+0x12a/0x3b0 mm/slub.c:4598<br /> l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]<br /> l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802<br /> l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241<br /> hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]<br /> hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265<br /> hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583<br /> abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917<br /> hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328<br /> process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231<br /> process_scheduled_works kernel/workqueue.c:3312 [inline]<br /> worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389<br /> kthread+0x2c1/0x3a0 kernel/kthread.c:389<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: prevent nf_skb_duplicated corruption<br /> <br /> syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write<br /> per-cpu variable nf_skb_duplicated in an unsafe way [1].<br /> <br /> Disabling preemption as hinted by the splat is not enough,<br /> we have to disable soft interrupts as well.<br /> <br /> [1]<br /> BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316<br /> caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87<br /> CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #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 /> check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49<br /> nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87<br /> nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]<br /> nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288<br /> nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23<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+0x2c4/0x450 include/linux/netfilter.h:269<br /> NF_HOOK_COND include/linux/netfilter.h:302 [inline]<br /> ip_output+0x185/0x230 net/ipv4/ip_output.c:433<br /> ip_local_out net/ipv4/ip_output.c:129 [inline]<br /> ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495<br /> udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981<br /> udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x1a6/0x270 net/socket.c:745<br /> ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597<br /> ___sys_sendmsg net/socket.c:2651 [inline]<br /> __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737<br /> __do_sys_sendmmsg net/socket.c:2766 [inline]<br /> __se_sys_sendmmsg net/socket.c:2763 [inline]<br /> __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f4ce4f7def9<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133<br /> RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9<br /> RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006<br /> RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> static_call: Replace pointless WARN_ON() in static_call_module_notify()<br /> <br /> static_call_module_notify() triggers a WARN_ON(), when memory allocation<br /> fails in __static_call_add_module().<br /> <br /> That&amp;#39;s not really justified, because the failure case must be correctly<br /> handled by the well known call chain and the error code is passed<br /> through to the initiating userspace application.<br /> <br /> A memory allocation fail is not a fatal problem, but the WARN_ON() takes<br /> the machine out when panic_on_warn is set.<br /> <br /> Replace it with a pr_warn().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: battery: Fix possible crash when unregistering a battery hook<br /> <br /> When a battery hook returns an error when adding a new battery, then<br /> the battery hook is automatically unregistered.<br /> However the battery hook provider cannot know that, so it will later<br /> call battery_hook_unregister() on the already unregistered battery<br /> hook, resulting in a crash.<br /> <br /> Fix this by using the list head to mark already unregistered battery<br /> hooks as already being unregistered so that they can be ignored by<br /> battery_hook_unregister().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix null-ptr-deref when journal load failed.<br /> <br /> During the mounting process, if journal_reset() fails because of too short<br /> journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. <br /> Subsequently, ocfs2_journal_shutdown() calls<br /> jbd2_journal_flush()-&gt;jbd2_cleanup_journal_tail()-&gt;<br /> __jbd2_update_log_tail()-&gt;jbd2_journal_update_sb_log_tail()<br /> -&gt;lock_buffer(journal-&gt;j_sb_buffer), resulting in a null-pointer<br /> dereference error.<br /> <br /> To resolve this issue, we should check the JBD2_LOADED flag to ensure the<br /> journal was properly loaded. Additionally, use journal instead of<br /> osb-&gt;journal directly to simplify the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix array out-of-bound access in SoC stats<br /> <br /> Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a<br /> maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process()<br /> function access ath12k_soc_dp_stats::hal_reo_error using the REO<br /> destination SRNG ring ID, which is incorrect. SRNG ring ID differ from<br /> normal ring ID, and this usage leads to out-of-bounds array access. To<br /> fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID<br /> directly instead of the SRNG ring ID to avoid out-of-bounds array access.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t readahead the relocation inode on RST<br /> <br /> On relocation we&amp;#39;re doing readahead on the relocation inode, but if the<br /> filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to<br /> preallocated extents not being mapped in the RST) from the lookup.<br /> <br /> But readahead doesn&amp;#39;t handle the error and submits invalid reads to the<br /> device, causing an assertion in the scatter-gather list code:<br /> <br /> BTRFS info (device nvme1n1): balance: start -d -m -s<br /> BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0<br /> BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0<br /> ------------[ cut here ]------------<br /> kernel BUG at include/linux/scatterlist.h:115!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567<br /> RIP: 0010:__blk_rq_map_sg+0x339/0x4a0<br /> RSP: 0018:ffffc90001a43820 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802<br /> RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000<br /> RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8<br /> R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000<br /> FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x14/0x25<br /> ? die+0x2e/0x50<br /> ? do_trap+0xca/0x110<br /> ? do_error_trap+0x65/0x80<br /> ? __blk_rq_map_sg+0x339/0x4a0<br /> ? exc_invalid_op+0x50/0x70<br /> ? __blk_rq_map_sg+0x339/0x4a0<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __blk_rq_map_sg+0x339/0x4a0<br /> nvme_prep_rq.part.0+0x9d/0x770<br /> nvme_queue_rq+0x7d/0x1e0<br /> __blk_mq_issue_directly+0x2a/0x90<br /> ? blk_mq_get_budget_and_tag+0x61/0x90<br /> blk_mq_try_issue_list_directly+0x56/0xf0<br /> blk_mq_flush_plug_list.part.0+0x52b/0x5d0<br /> __blk_flush_plug+0xc6/0x110<br /> blk_finish_plug+0x28/0x40<br /> read_pages+0x160/0x1c0<br /> page_cache_ra_unbounded+0x109/0x180<br /> relocate_file_extent_cluster+0x611/0x6a0<br /> ? btrfs_search_slot+0xba4/0xd20<br /> ? balance_dirty_pages_ratelimited_flags+0x26/0xb00<br /> relocate_data_extent.constprop.0+0x134/0x160<br /> relocate_block_group+0x3f2/0x500<br /> btrfs_relocate_block_group+0x250/0x430<br /> btrfs_relocate_chunk+0x3f/0x130<br /> btrfs_balance+0x71b/0xef0<br /> ? kmalloc_trace_noprof+0x13b/0x280<br /> btrfs_ioctl+0x2c2e/0x3030<br /> ? kvfree_call_rcu+0x1e6/0x340<br /> ? list_lru_add_obj+0x66/0x80<br /> ? mntput_no_expire+0x3a/0x220<br /> __x64_sys_ioctl+0x96/0xc0<br /> do_syscall_64+0x54/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fcc04514f9b<br /> Code: Unable to access opcode bytes at 0x7fcc04514f71.<br /> RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b<br /> RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001<br /> R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5<br /> R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:__blk_rq_map_sg+0x339/0x4a0<br /> RSP: 0018:ffffc90001a43820 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802<br /> RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000<br /> RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8<br /> R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000<br /> FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0<br /> Kernel p<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: prevent possible tunnel refcount underflow<br /> <br /> When a session is created, it sets a backpointer to its tunnel. When<br /> the session refcount drops to 0, l2tp_session_free drops the tunnel<br /> refcount if session-&gt;tunnel is non-NULL. However, session-&gt;tunnel is<br /> set in l2tp_session_create, before the tunnel refcount is incremented<br /> by l2tp_session_register, which leaves a small window where<br /> session-&gt;tunnel is non-NULL when the tunnel refcount hasn&amp;#39;t been<br /> bumped.<br /> <br /> Moving the assignment to l2tp_session_register is trivial but<br /> l2tp_session_create calls l2tp_session_set_header_len which uses<br /> session-&gt;tunnel to get the tunnel&amp;#39;s encap. Add an encap arg to<br /> l2tp_session_set_header_len to avoid using session-&gt;tunnel.<br /> <br /> If l2tpv3 sessions have colliding IDs, it is possible for<br /> l2tp_v3_session_get to race with l2tp_session_register and fetch a<br /> session which doesn&amp;#39;t yet have session-&gt;tunnel set. Add a check for<br /> this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()<br /> <br /> In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may<br /> return a NULL pointer, leading to a scenario where `label-&gt;str` is accessed<br /> without verifying if `label` itself is NULL.<br /> <br /> This patch adds a proper NULL check for `label` before accessing<br /> `label-&gt;str`. The check for `label-&gt;str != NULL` is removed because<br /> `label-&gt;str` can never be NULL if `label` is not NULL.<br /> <br /> This fixes the issue where the label name was being printed as `(efault)`<br /> when dumping the sysfs GPIO file when `label == NULL`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Prevent null pointer access in xe_migrate_copy<br /> <br /> xe_migrate_copy designed to copy content of TTM resources. When source<br /> resource is null, it will trigger a NULL pointer dereference in<br /> xe_migrate_copy. To avoid this situation, update lacks source flag to<br /> true for this case, the flag will trigger xe_migrate_clear rather than<br /> xe_migrate_copy.<br /> <br /> Issue trace:<br /> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14,<br /> sizes: 4194304 &amp; 4194304<br /> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15,<br /> sizes: 4194304 &amp; 4194304<br /> [317.128055] BUG: kernel NULL pointer dereference, address:<br /> 0000000000000010<br /> [317.128064] #PF: supervisor read access in kernel mode<br /> [317.128066] #PF: error_code(0x0000) - not-present page<br /> [317.128069] PGD 0 P4D 0<br /> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted:<br /> G U N 6.11.0-rc7-xe #1<br /> [317.128078] Tainted: [U]=USER, [N]=TEST<br /> [317.128080] Hardware name: Intel Corporation Lunar Lake Client<br /> Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024<br /> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe]<br /> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8<br /> fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31<br /> ff 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff<br /> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246<br /> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX:<br /> 0000000000000000<br /> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI:<br /> 0000000000000000<br /> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09:<br /> 0000000000000001<br /> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12:<br /> ffff88814e7b1f08<br /> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15:<br /> 0000000000000001<br /> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000)<br /> knlGS:0000000000000000<br /> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4:<br /> 0000000000770ef0<br /> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:<br /> 0000000000000400<br /> [317.128184] PKRU: 55555554<br /> [317.128185] Call Trace:<br /> [317.128187] <br /> [317.128189] ? show_regs+0x67/0x70<br /> [317.128194] ? __die_body+0x20/0x70<br /> [317.128196] ? __die+0x2b/0x40<br /> [317.128198] ? page_fault_oops+0x15f/0x4e0<br /> [317.128203] ? do_user_addr_fault+0x3fb/0x970<br /> [317.128205] ? lock_acquire+0xc7/0x2e0<br /> [317.128209] ? exc_page_fault+0x87/0x2b0<br /> [317.128212] ? asm_exc_page_fault+0x27/0x30<br /> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe]<br /> [317.128263] ? __lock_acquire+0xb9d/0x26f0<br /> [317.128265] ? __lock_acquire+0xb9d/0x26f0<br /> [317.128267] ? sg_free_append_table+0x20/0x80<br /> [317.128271] ? lock_acquire+0xc7/0x2e0<br /> [317.128273] ? mark_held_locks+0x4d/0x80<br /> [317.128275] ? trace_hardirqs_on+0x1e/0xd0<br /> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60<br /> [317.128281] ? __pm_runtime_resume+0x60/0xa0<br /> [317.128284] xe_bo_move+0x682/0xc50 [xe]<br /> [317.128315] ? lock_is_held_type+0xaa/0x120<br /> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm]<br /> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm]<br /> [317.128328] shrink_test_run_device+0x721/0xc10 [xe]<br /> [317.128360] ? find_held_lock+0x31/0x90<br /> [317.128363] ? lock_release+0xd1/0x2a0<br /> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10<br /> [kunit]<br /> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe]<br /> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit]<br /> [317.128400] ? trace_hardirqs_on+0x1e/0xd0<br /> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60<br /> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku<br /> ---truncated---