Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imx/tve: fix probe device leak<br /> <br /> Make sure to drop the reference taken to the DDC device during probe on<br /> probe failure (e.g. probe deferral) and on driver unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> flex_proportions: make fprop_new_period() hardirq safe<br /> <br /> Bernd has reported a lockdep splat from flexible proportions code that is<br /> essentially complaining about the following race:<br /> <br /> <br /> run_timer_softirq - we are in softirq context<br /> call_timer_fn<br /> writeout_period<br /> fprop_new_period<br /> write_seqcount_begin(&amp;p-&gt;sequence);<br /> <br /> <br /> ...<br /> blk_mq_end_request()<br /> blk_update_request()<br /> ext4_end_bio()<br /> folio_end_writeback()<br /> __wb_writeout_add()<br /> __fprop_add_percpu_max()<br /> if (unlikely(max_frac sequence);<br /> - sees odd sequence so loops indefinitely<br /> <br /> Note that a deadlock like this is only possible if the bdi has configured<br /> maximum fraction of writeout throughput which is very rare in general but<br /> frequent for example for FUSE bdis. To fix this problem we have to make<br /> sure write section of the sequence counter is irqsafe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: TC, delete flows only for existing peers<br /> <br /> When deleting TC steering flows, iterate only over actual devcom<br /> peers instead of assuming all possible ports exist. This avoids<br /> touching non-existent peers and ensures cleanup is limited to<br /> devices the driver is currently connected to.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 133c8a067 P4D 0<br /> Oops: Oops: 0002 [#1] SMP<br /> CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core]<br /> Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49<br /> RSP: 0018:ff11000143867528 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000<br /> RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0<br /> RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002<br /> R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78<br /> R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0<br /> FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0<br /> Call Trace:<br /> <br /> mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]<br /> mlx5e_flow_put+0x25/0x50 [mlx5_core]<br /> mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core]<br /> tc_setup_cb_reoffload+0x20/0x80<br /> fl_reoffload+0x26f/0x2f0 [cls_flower]<br /> ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]<br /> ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]<br /> tcf_block_playback_offloads+0x9e/0x1c0<br /> tcf_block_unbind+0x7b/0xd0<br /> tcf_block_setup+0x186/0x1d0<br /> tcf_block_offload_cmd.isra.0+0xef/0x130<br /> tcf_block_offload_unbind+0x43/0x70<br /> __tcf_block_put+0x85/0x160<br /> ingress_destroy+0x32/0x110 [sch_ingress]<br /> __qdisc_destroy+0x44/0x100<br /> qdisc_graft+0x22b/0x610<br /> tc_get_qdisc+0x183/0x4d0<br /> rtnetlink_rcv_msg+0x2d7/0x3d0<br /> ? rtnl_calcit.isra.0+0x100/0x100<br /> netlink_rcv_skb+0x53/0x100<br /> netlink_unicast+0x249/0x320<br /> ? __alloc_skb+0x102/0x1f0<br /> netlink_sendmsg+0x1e3/0x420<br /> __sock_sendmsg+0x38/0x60<br /> ____sys_sendmsg+0x1ef/0x230<br /> ? copy_msghdr_from_user+0x6c/0xa0<br /> ___sys_sendmsg+0x7f/0xc0<br /> ? ___sys_recvmsg+0x8a/0xc0<br /> ? __sys_sendto+0x119/0x180<br /> __sys_sendmsg+0x61/0xb0<br /> do_syscall_64+0x55/0x640<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f35238bb764<br /> Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55<br /> RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764<br /> RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003<br /> RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20<br /> R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790<br /> R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix race in mptcp_pm_nl_flush_addrs_doit()<br /> <br /> syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()<br /> and/or mptcp_pm_nl_is_backup()<br /> <br /> Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()<br /> which is not RCU ready.<br /> <br /> list_splice_init_rcu() can not be called here while holding pernet-&gt;lock<br /> spinlock.<br /> <br /> Many thanks to Eulgyu Kim for providing a repro and testing our patches.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix use-after-free due to enslave fail after slave array update<br /> <br /> Fix a use-after-free which happens due to enslave failure after the new<br /> slave has been added to the array. Since the new slave can be used for Tx<br /> immediately, we can use it after it has been freed by the enslave error<br /> cleanup path which frees the allocated slave memory. Slave update array is<br /> supposed to be called last when further enslave failures are not expected.<br /> Move it after xdp setup to avoid any problems.<br /> <br /> It is very easy to reproduce the problem with a simple xdp_pass prog:<br /> ip l add bond1 type bond mode balance-xor<br /> ip l set bond1 up<br /> ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass<br /> ip l add dumdum type dummy<br /> <br /> Then run in parallel:<br /> while :; do ip l set dumdum master bond1 1&gt;/dev/null 2&gt;&amp;1; done;<br /> mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"<br /> <br /> The crash happens almost immediately:<br /> [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI<br /> [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]<br /> [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary)<br /> [ 605.602979] Tainted: [B]=BAD_PAGE<br /> [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210<br /> [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89<br /> [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213<br /> [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000<br /> [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be<br /> [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c<br /> [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000<br /> [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84<br /> [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000<br /> [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0<br /> [ 605.603373] Call Trace:<br /> [ 605.603392] <br /> [ 605.603410] __dev_queue_xmit+0x448/0x32a0<br /> [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10<br /> [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10<br /> [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10<br /> [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding]<br /> [ 605.603546] ? _printk+0xcb/0x100<br /> [ 605.603566] ? __pfx__printk+0x10/0x10<br /> [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding]<br /> [ 605.603627] ? add_taint+0x5e/0x70<br /> [ 605.603648] ? add_taint+0x2a/0x70<br /> [ 605.603670] ? end_report.cold+0x51/0x75<br /> [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding]<br /> [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: t7xx: fix potential skb-&gt;frags overflow in RX path<br /> <br /> When receiving data in the DPMAIF RX path,<br /> the t7xx_dpmaif_set_frag_to_skb() function adds<br /> page fragments to an skb without checking if the number of<br /> fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow<br /> in skb_shinfo(skb)-&gt;frags[] array, corrupting adjacent memory and<br /> potentially causing kernel crashes or other undefined behavior.<br /> <br /> This issue was identified through static code analysis by comparing with a<br /> similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76:<br /> fix array overflow on receiving too many fragments for a packet").<br /> <br /> The vulnerability could be triggered if the modem firmware sends packets<br /> with excessive fragments. While under normal protocol conditions (MTU 3080<br /> bytes, BAT buffer 3584 bytes),<br /> a single packet should not require additional<br /> fragments, the kernel should not blindly trust firmware behavior.<br /> Malicious, buggy, or compromised firmware could potentially craft packets<br /> with more fragments than the kernel expects.<br /> <br /> Fix this by adding a bounds check before calling skb_add_rx_frag() to<br /> ensure nr_frags does not exceed MAX_SKB_FRAGS.<br /> <br /> The check must be performed before unmapping to avoid a page leak<br /> and double DMA unmap during device teardown.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nci: Fix race between rfkill and nci_unregister_device().<br /> <br /> syzbot reported the splat below [0] without a repro.<br /> <br /> It indicates that struct nci_dev.cmd_wq had been destroyed before<br /> nci_close_device() was called via rfkill.<br /> <br /> nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which<br /> (I think) was called from virtual_ncidev_close() when syzbot close()d<br /> an fd of virtual_ncidev.<br /> <br /> The problem is that nci_unregister_device() destroys nci_dev.cmd_wq<br /> first and then calls nfc_unregister_device(), which removes the<br /> device from rfkill by rfkill_unregister().<br /> <br /> So, the device is still visible via rfkill even after nci_dev.cmd_wq<br /> is destroyed.<br /> <br /> Let&amp;#39;s unregister the device from rfkill first in nci_unregister_device().<br /> <br /> Note that we cannot call nfc_unregister_device() before<br /> nci_close_device() because<br /> <br /> 1) nfc_unregister_device() calls device_del() which frees<br /> all memory allocated by devm_kzalloc() and linked to<br /> ndev-&gt;conn_info_list<br /> <br /> 2) nci_rx_work() could try to queue nci_conn_info to<br /> ndev-&gt;conn_info_list which could be leaked<br /> <br /> Thus, nfc_unregister_device() is split into two functions so we<br /> can remove rfkill interfaces only before nci_close_device().<br /> <br /> [0]:<br /> DEBUG_LOCKS_WARN_ON(1)<br /> WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349<br /> WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349<br /> WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026<br /> RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]<br /> RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline]<br /> RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187<br /> Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f<br /> RSP: 0018:ffffc9000c767680 EFLAGS: 00010046<br /> RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000<br /> RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0<br /> RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4<br /> R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2<br /> R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30<br /> FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868<br /> touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940<br /> __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982<br /> nci_close_device+0x302/0x630 net/nfc/nci/core.c:567<br /> nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639<br /> nfc_dev_down+0x152/0x290 net/nfc/core.c:161<br /> nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179<br /> rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346<br /> rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301<br /> vfs_write+0x29a/0xb90 fs/read_write.c:684<br /> ksys_write+0x150/0x270 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fa59b39acb9<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9<br /> RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007<br /> RBP: 00007fa59b408bf7 R08: <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues<br /> <br /> Add NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashes<br /> during resume from suspend when rings[q_idx]-&gt;q_vector is NULL.<br /> <br /> Tested adaptor:<br /> 60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02)<br /> Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]<br /> <br /> SR-IOV state: both disabled and enabled can reproduce this issue.<br /> <br /> kernel version: v6.18<br /> <br /> Reproduce steps:<br /> Boot up and execute suspend like systemctl suspend or rtcwake.<br /> <br /> Log:<br /> [ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040<br /> [ 231.444052] #PF: supervisor read access in kernel mode<br /> [ 231.444484] #PF: error_code(0x0000) - not-present page<br /> [ 231.444913] PGD 0 P4D 0<br /> [ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170<br /> [ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89<br /> [ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202<br /> [ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010<br /> [ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000<br /> [ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000<br /> [ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<br /> [ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000<br /> [ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000<br /> [ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0<br /> [ 231.451629] PKRU: 55555554<br /> [ 231.452076] Call Trace:<br /> [ 231.452549] <br /> [ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice]<br /> [ 231.453482] ice_resume+0xfd/0x220 [ice]<br /> [ 231.453977] ? __pfx_pci_pm_resume+0x10/0x10<br /> [ 231.454425] pci_pm_resume+0x8c/0x140<br /> [ 231.454872] ? __pfx_pci_pm_resume+0x10/0x10<br /> [ 231.455347] dpm_run_callback+0x5f/0x160<br /> [ 231.455796] ? dpm_wait_for_superior+0x107/0x170<br /> [ 231.456244] device_resume+0x177/0x270<br /> [ 231.456708] dpm_resume+0x209/0x2f0<br /> [ 231.457151] dpm_resume_end+0x15/0x30<br /> [ 231.457596] suspend_devices_and_enter+0x1da/0x2b0<br /> [ 231.458054] enter_state+0x10e/0x570<br /> <br /> Add defensive checks for both the ring pointer and its q_vector<br /> before dereferencing, allowing the system to resume successfully even when<br /> q_vectors are unmapped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: fix deadlock in RSS config read<br /> <br /> Since cited commit, core locks the net_device&amp;#39;s rss_lock when handling<br /> ethtool -x command, so driver&amp;#39;s implementation should not lock it<br /> again. Remove the latter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rocker: fix memory leak in rocker_world_port_post_fini()<br /> <br /> In rocker_world_port_pre_init(), rocker_port-&gt;wpriv is allocated with<br /> kzalloc(wops-&gt;port_priv_size, GFP_KERNEL). However, in<br /> rocker_world_port_post_fini(), the memory is only freed when<br /> wops-&gt;port_post_fini callback is set:<br /> <br /> if (!wops-&gt;port_post_fini)<br /> return;<br /> wops-&gt;port_post_fini(rocker_port);<br /> kfree(rocker_port-&gt;wpriv);<br /> <br /> Since rocker_ofdpa_ops does not implement port_post_fini callback<br /> (it is NULL), the wpriv memory allocated for each port is never freed<br /> when ports are removed. This leads to a memory leak of<br /> sizeof(struct ofdpa_port) bytes per port on every device removal.<br /> <br /> Fix this by always calling kfree(rocker_port-&gt;wpriv) regardless of<br /> whether the port_post_fini callback exists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove<br /> <br /> On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and<br /> ih2 interrupt ring buffers are not initialized. This is by design, as<br /> these secondary IH rings are only available on discrete GPUs. See<br /> vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when<br /> AMD_IS_APU is set.<br /> <br /> However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to<br /> get the timestamp of the last interrupt entry. When retry faults are<br /> enabled on APUs (noretry=0), this function is called from the SVM page<br /> fault recovery path, resulting in a NULL pointer dereference when<br /> amdgpu_ih_decode_iv_ts_helper() attempts to access ih-&gt;ring[].<br /> <br /> The crash manifests as:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000004<br /> RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]<br /> Call Trace:<br /> amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]<br /> svm_range_restore_pages+0xae5/0x11c0 [amdgpu]<br /> amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]<br /> gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]<br /> amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]<br /> amdgpu_ih_process+0x84/0x100 [amdgpu]<br /> <br /> This issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HW<br /> IP 9.3.0 from noretry=1") which changed the default for Renoir APU from<br /> noretry=1 to noretry=0, enabling retry fault handling and thus<br /> exercising the buggy code path.<br /> <br /> Fix this by adding a check for ih1.ring_size before attempting to use<br /> it. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu:<br /> Rework retry fault removal"). This is needed if the hardware doesn&amp;#39;t<br /> support secondary HW IH rings.<br /> <br /> v2: additional updates (Alex)<br /> <br /> (cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/nvm: Fix double-free on aux add failure<br /> <br /> After a successful auxiliary_device_init(), aux_dev-&gt;dev.release<br /> (xe_nvm_release_dev()) is responsible for the kfree(nvm). When<br /> there is failure with auxiliary_device_add(), driver will call<br /> auxiliary_device_uninit(), which call put_device(). So that the<br /> .release callback will be triggered to free the memory associated<br /> with the auxiliary_device.<br /> <br /> Move the kfree(nvm) into the auxiliary_device_init() failure path<br /> and remove the err goto path to fix below error.<br /> <br /> "<br /> [ 13.232905] ==================================================================<br /> [ 13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe]<br /> [ 13.233112] Free of addr ffff888120635000 by task systemd-udevd/273<br /> <br /> [ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary)<br /> ...<br /> [ 13.233125] Call Trace:<br /> [ 13.233126] <br /> [ 13.233127] dump_stack_lvl+0x7f/0xc0<br /> [ 13.233132] print_report+0xce/0x610<br /> [ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0<br /> [ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe]<br /> ...<br /> "<br /> <br /> v2: drop err goto path. (Alexander)<br /> <br /> (cherry picked from commit a3187c0c2bbd947ffff97f90d077ac88f9c2a215)