slab-use-after-free in event_property_validate (amdgpu_dm_hdcp.c)

This should hopefully fix your issue:

https://lore.kernel.org/amd-gfx/20250305051402.1550046-19-chiahsuan.chung@amd.com/T/#u

closed

mentioned in commit agd5f/linux@725a04ba

Thanks for the patch! It was not until today that I found some time to apply it (not the whole patchset) and test it out. However, it didn't seem to fix the SUAF entirely. The SUAF still occured from time to time, but this time, I was sure that it was more likely to happen when plugging out or in my USB-C DP Alt dock. Unlike 6.13, there were no drm printk()s around the SUAF oops (just some random USB or NIC stuff related to the dock).

6.14-rc6 + https://lore.kernel.org/amd-gfx/20250305051402.1550046-19-chiahsuan.chung@amd.com/T/#u

[ 3890.452089] ==================================================================
[ 3890.452262] BUG: KASAN: slab-use-after-free in event_property_validate (drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:381) amdgpu
[ 3890.454969] Read of size 4 at addr ffff8881803540b0 by task kworker/16:1/177

[ 3890.454994] CPU: 16 UID: 0 PID: 177 Comm: kworker/16:1 Tainted: G    BU  W          6.14.0-rc6 #1 f124040fe8c47b4ce92201466a9ca6d8e890ae39
[ 3890.455007] Tainted: [B]=BAD_PAGE, [U]=USER, [W]=WARN
[ 3890.455010] Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN22WW 10/16/2024
[ 3890.455017] Workqueue: events event_property_validate [amdgpu]
[ 3890.455650] Call Trace:
[ 3890.455660]  <TASK>
[ 3890.455669] dump_stack_lvl (lib/dump_stack.c:122)
[ 3890.455704] ? event_property_validate (drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:381) amdgpu
[ 3890.456356] print_report (mm/kasan/report.c:409 (discriminator 1) mm/kasan/report.c:521 (discriminator 1))
[ 3890.456381] ? _raw_write_unlock_irqrestore (kernel/locking/spinlock.c:161)
[ 3890.456399] ? psi_group_change (arch/x86/include/asm/bitops.h:206 (discriminator 1) arch/x86/include/asm/bitops.h:238 (discriminator 1) include/asm-generic/bitops/instrumented-non-atomic.h:142 (discriminator 1) kernel/sched/psi.c:872 (discriminator 1))
[ 3890.456417] ? event_property_validate (drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:381) amdgpu
[ 3890.457063] kasan_report (mm/kasan/report.c:636)
[ 3890.457083] ? event_property_validate (drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:381) amdgpu
[ 3890.457737] event_property_validate (drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:381) amdgpu
[ 3890.458387] ? __cancel_work (arch/x86/include/asm/atomic64_64.h:20 include/linux/atomic/atomic-arch-fallback.h:2629 include/linux/atomic/atomic-long.h:79 include/linux/atomic/atomic-instrumented.h:3224 kernel/workqueue.c:789 kernel/workqueue.c:816 kernel/workqueue.c:4342)
[ 3890.458409] ? enable_assr (drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:364) amdgpu
[ 3890.459060] ? _raw_write_lock_irq (kernel/locking/spinlock.c:169)
[ 3890.459085] process_one_work (kernel/workqueue.c:3238)
[ 3890.459108] worker_thread (kernel/workqueue.c:3313 (discriminator 2) kernel/workqueue.c:3400 (discriminator 2))
[ 3890.459121] ? __kthread_parkme (arch/x86/include/asm/bitops.h:206 (discriminator 1) arch/x86/include/asm/bitops.h:238 (discriminator 1) include/asm-generic/bitops/instrumented-non-atomic.h:142 (discriminator 1) kernel/kthread.c:291 (discriminator 1))
[ 3890.459135] ? rescuer_thread (kernel/workqueue.c:3346)
[ 3890.459142] kthread (kernel/kthread.c:464)
[ 3890.459148] ? kthread_is_per_cpu (kernel/kthread.c:413)
[ 3890.459158] ? _raw_write_lock_irq (kernel/locking/spinlock.c:169)
[ 3890.459171] ? kthread_is_per_cpu (kernel/kthread.c:413)
[ 3890.459181] ret_from_fork (arch/x86/kernel/process.c:148)
[ 3890.459194] ? kthread_is_per_cpu (kernel/kthread.c:413)
[ 3890.459203] ret_from_fork_asm (arch/x86/entry/entry_64.S:254)
[ 3890.459222]  </TASK>

[ 3890.459323] Allocated by task 5380 on cpu 16 at 3889.559954s:
[ 3890.459334] kasan_save_stack (mm/kasan/common.c:48)
[ 3890.459361] kasan_save_track (mm/kasan/common.c:54 (discriminator 4) mm/kasan/common.c:69 (discriminator 4))
[ 3890.459376] __kasan_kmalloc (mm/kasan/common.c:377 mm/kasan/common.c:394)
[ 3890.459390] proc_pid_readlink (fs/proc/base.c:1825 fs/proc/base.c:1857)
[ 3890.459410] vfs_readlink (fs/namei.c:5311)
[ 3890.459423] do_readlinkat (fs/stat.c:578)
[ 3890.459437] __x64_sys_readlinkat (fs/stat.c:592)
[ 3890.459449] do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
[ 3890.459467] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

[ 3890.459497] Freed by task 5380 on cpu 16 at 3889.559956s:
[ 3890.459508] kasan_save_stack (mm/kasan/common.c:48)
[ 3890.459513] kasan_save_track (mm/kasan/common.c:54 (discriminator 4) mm/kasan/common.c:69 (discriminator 4))
[ 3890.459522] kasan_save_free_info (mm/kasan/generic.c:579 (discriminator 1))
[ 3890.459538] __kasan_slab_free (mm/kasan/common.c:271)
[ 3890.459550] kfree (mm/slub.c:4609 (discriminator 3) mm/slub.c:4757 (discriminator 3))
[ 3890.459573] proc_pid_readlink (fs/proc/base.c:1858)
[ 3890.459586] vfs_readlink (fs/namei.c:5311)
[ 3890.459599] do_readlinkat (fs/stat.c:578)
[ 3890.459607] __x64_sys_readlinkat (fs/stat.c:592)
[ 3890.459615] do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
[ 3890.459628] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

[ 3890.459650] The buggy address belongs to the object at ffff888180354000
which belongs to the cache kmalloc-4k of size 4096
[ 3890.459670] The buggy address is located 176 bytes inside of
freed 4096-byte region [ffff888180354000, ffff888180355000)

[ 3890.459690] The buggy address belongs to the physical page:
[ 3890.459699] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x180350
[ 3890.459715] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[ 3890.459724] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
[ 3890.459744] page_type: f5(slab)
[ 3890.459759] raw: 0017ffffc0000040 ffff888100043040 dead000000000122 0000000000000000
[ 3890.459767] raw: 0000000000000000 0000000000040004 00000000f5000000 0000000000000000
[ 3890.459772] head: 0017ffffc0000040 ffff888100043040 dead000000000122 0000000000000000
[ 3890.459781] head: 0000000000000000 0000000000040004 00000000f5000000 0000000000000000
[ 3890.459791] head: 0017ffffc0000003 ffffea000600d401 ffffffffffffffff 0000000000000000
[ 3890.459796] head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
[ 3890.459801] page dumped because: kasan: bad access detected

[ 3890.459818] Memory state around the buggy address:
[ 3890.459831]  ffff888180353f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3890.459844]  ffff888180354000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3890.459851] >ffff888180354080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3890.459855]                                      ^
[ 3890.459859]  ffff888180354100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3890.459865]  ffff888180354180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3890.459869] ==================================================================

reopened

mentioned in commit agd5f/linux@e65e7bea

I was sure that it was more likely to happen when plugging out or in my USB-C DP Alt dock

After more tests, I found that the SUAF follows the pattern:

Sometimes, it doesn't happen at all. If this is the case, it will not happen until the next boot, no matter what I do. The probability of booting into such a peace is around 30%.
Otherwise, it may happen when:

Dock/undock (very likely).
Change resolution (likely).
Poweroff/reboot (less likely).

After the patch, there is either no DRM printk() DRM around the SUAF or, if any, DRM printk() is relatively far from the SUAF. This hints that the patch did fix one of the SUAF triggers.
Besides the weird alloc/free pattern in my previous reply, I also observed some identical patterns compared to the v6.14-rc4 one.

I am doing some ftrace tricks¹ to see if I can reveal more details from the hidden iceberg.

dmesg -W & perf --no-pager ftrace trace --func-opts call-graph -T hdcp_destroy -T hdcp_reset_display -T hdcp_update_display -T hdcp_update_display -T process_output -T event_property_validate -T hdcp_create_workqueue ; kill %% ↩

Thanks for the patch! It was not until today that I found some time to apply it (not the whole patchset) and test it out. However, it didn't seem to fix the SUAF entirely. The SUAF still occured from time to time, but this time, I was sure that it was more likely to happen when plugging out or in my USB-C DP Alt dock. Unlike 6.13, there were no drm printk()s around the SUAF oops (just some random USB or NIC stuff related to the dock).

After the patch, there is either no DRM printk() DRM around the SUAF or, if any, DRM printk() is relatively far from the SUAF. This hints that the patch did fix one of the SUAF triggers.

Yeah at least it sounds like it was a correct fix but there is a secondary SUAF issue. This looks like it's going to be a tougher SUAF to iron out.

I'm confused how that patch could have ever fixed this issue. Was it tested? The patch alters hdcp_destroy, but hdcp_destroy is only ever called from amdgpu_dm_fini. It isn't called when plugging and unplugging a USB-C dock.

You're right. After tracing hdcp_destroy with bpftrace, I found it never being called when disabling/enabling monitors or plugging/unplugging docks.

Yes; it looks like it was a secondary issue I found when trying to find possible causes of this issue.

I think that the direction that Chris found which he summarized in [BUG] drm_connector reference counting and USB-C docks is more likely the root cause.

UBSAN: shift-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:4568 occurs because vcpi==0 in this payload, so BIT op is a left-shift by -1.

A quick journal review confirms the shift-out-of-bounds. I've used v6.14-rc6 kernel with KASAN and UBSAN since March 11 and SOOB appeared only twice, on March 11 and March 13. Each time it appeared, a SUAF in event_property_validate followed after. Plz let me know if you need further logs.

Actually this looks independent of the other issue (though hitting the other issue will also cause this one to be hit).

Can you try the attached patch? hdcp_remove_display was actually copying the pointer before whereas it looks like it should be removing it. So I changed that. Hopefully someone who understands the code better can verify if that's correct...

0001-drm-amd-display-Fix-slab-use-after-free-in-hdcp.patch

@alex.hung can you take a look at above patch?

I am doing some ftrace tricks to see if I can reveal more details from the hidden iceberg.

Quick update: I failed to get useful ftrace results as I either met SUAF when rebooting or I forgot to run ftrace

But I did get some interesting KASAN report!

On reboot, I met a mostly identical stacktrace to the 6.14-rc4 one (freed by `drm_client_modeset_probe` just before):

[19750.072500] tb kernel: ==================================================================
[19750.072786] tb kernel: BUG: KASAN: slab-use-after-free in event_property_validate+0x3da/0x580 [amdgpu]
[19750.072825] tb kernel: Read of size 4 at addr ffff88815f2300b0 by task kworker/9:2/23073
[19750.072850] tb kernel:
[19750.072901] tb kernel: CPU: 9 UID: 0 PID: 23073 Comm: kworker/9:2 Tainted: G     U  W          6.14.0-rc6 #1 f124040fe8c47b4ce92201466a9ca6d8e890ae39
[19750.072953] tb kernel: Tainted: [U]=USER, [W]=WARN
[19750.072962] tb kernel: Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN22WW 10/16/2024
[19750.073012] tb kernel: Workqueue: events event_property_validate [amdgpu]
[19750.073047] tb kernel: Call Trace:
[19750.073115] tb kernel:  <TASK>
[19750.073145] tb kernel:  dump_stack_lvl+0x5d/0x80
[19750.073215] tb kernel:  ? event_property_validate+0x3da/0x580 [amdgpu 64199d377d2ec1d23f3a57c1f2d973d0c0c48e25]
[19750.073288] tb kernel:  print_report+0x174/0x516
[19750.073468] tb kernel:  ? _raw_write_unlock_irqrestore+0x80/0x80
[19750.073553] tb kernel:  ? psi_group_change+0x433/0x9b0
[19750.073620] tb kernel:  ? event_property_validate+0x3da/0x580 [amdgpu 64199d377d2ec1d23f3a57c1f2d973d0c0c48e25]
[19750.073662] tb kernel:  kasan_report+0xef/0x150
[19750.073704] tb kernel:  ? event_property_validate+0x3da/0x580 [amdgpu 64199d377d2ec1d23f3a57c1f2d973d0c0c48e25]
[19750.073758] tb kernel:  event_property_validate+0x3da/0x580 [amdgpu 64199d377d2ec1d23f3a57c1f2d973d0c0c48e25]
[19750.073816] tb kernel:  ? queue_work_on+0x95/0xa0
[19750.073922] tb kernel:  ? enable_assr+0x270/0x270 [amdgpu 64199d377d2ec1d23f3a57c1f2d973d0c0c48e25]
[19750.073940] tb kernel:  ? io_schedule_timeout+0x130/0x130
[19750.073980] tb kernel:  process_one_work+0x65c/0xf50
[19750.074000] tb kernel:  worker_thread+0x78c/0x1270
[19750.074039] tb kernel:  ? rescuer_thread+0x15a0/0x15a0
[19750.074046] tb kernel:  kthread+0x359/0x7a0
[19750.074074] tb kernel:  ? kthread_is_per_cpu+0xd0/0xd0
[19750.074117] tb kernel:  ? _raw_write_lock_irq+0xe0/0xe0
[19750.074132] tb kernel:  ? kthread_is_per_cpu+0xd0/0xd0
[19750.074148] tb kernel:  ret_from_fork+0x4d/0x80
[19750.074182] tb kernel:  ? kthread_is_per_cpu+0xd0/0xd0
[19750.074197] tb kernel:  ret_from_fork_asm+0x11/0x20
[19750.074230] tb kernel:  </TASK>
[19750.074277] tb kernel:
[19750.074292] tb kernel: Allocated by task 72 on cpu 8 at 16.097040s:
[19750.074307] tb kernel:  kasan_save_stack+0x44/0x80
[19750.074338] tb kernel:  kasan_save_track+0x25/0x80
[19750.074371] tb kernel:  __kasan_kmalloc+0xc2/0xd0
[19750.074414] tb kernel:  dm_dp_add_mst_connector+0x82/0x5a0 [amdgpu]
[19750.074452] tb kernel:  drm_dp_mst_port_add_connector+0x418/0x6f0 [drm_display_helper]
[19750.074479] tb kernel:  drm_dp_send_link_address+0x13bb/0x29d0 [drm_display_helper]
[19750.074530] tb kernel:  drm_dp_check_and_send_link_address+0x16f/0x1f0 [drm_display_helper]
[19750.074545] tb kernel:  drm_dp_mst_link_probe_work+0x26d/0x3f0 [drm_display_helper]
[19750.074560] tb kernel:  process_one_work+0x65c/0xf50
[19750.074574] tb kernel:  worker_thread+0x78c/0x1270
[19750.074589] tb kernel:  kthread+0x359/0x7a0
[19750.074606] tb kernel:  ret_from_fork+0x4d/0x80
[19750.074613] tb kernel:  ret_from_fork_asm+0x11/0x20
[19750.074632] tb kernel:
[19750.074665] tb kernel: Freed by task 2089 on cpu 9 at 19749.785655s:
[19750.074681] tb kernel:  kasan_save_stack+0x44/0x80
[19750.074697] tb kernel:  kasan_save_track+0x25/0x80
[19750.075070] tb kernel:  kasan_save_free_info+0x3b/0x60
[19750.075110] tb kernel:  __kasan_slab_free+0x4e/0x70
[19750.075151] tb kernel:  kfree+0x12d/0x440
[19750.075176] tb kernel:  drm_client_modeset_probe+0x2587/0x54d0
[19750.075185] tb kernel:  drm_fb_helper_hotplug_event+0x24e/0x420
[19750.075234] tb kernel:  __drm_fb_helper_restore_fbdev_mode_unlocked+0x166/0x1a0
[19750.075287] tb kernel:  drm_fb_helper_set_par+0xbd/0x100
[19750.075331] tb kernel:  fb_set_var+0x6e2/0x1020
[19750.075345] tb kernel:  fbcon_blank+0x60a/0xe50
[19750.075369] tb kernel:  do_unblank_screen+0x1f8/0x3f0
[19750.075404] tb kernel:  vt_ioctl+0x8ea/0x2100
[19750.075430] tb kernel:  tty_ioctl+0x206/0x11e0
[19750.075463] tb kernel:  __x64_sys_ioctl+0x160/0x1d0
[19750.075498] tb kernel:  do_syscall_64+0x6d/0x140
[19750.075535] tb kernel:  entry_SYSCALL_64_after_hwframe+0x6c/0x74
[19750.075580] tb kernel:
[19750.075587] tb kernel: The buggy address belongs to the object at ffff88815f230000
                           which belongs to the cache kmalloc-8k of size 8192
[19750.075614] tb kernel: The buggy address is located 176 bytes inside of
                           freed 8192-byte region [ffff88815f230000, ffff88815f232000)
[19750.075639] tb kernel:
[19750.075645] tb kernel: The buggy address belongs to the physical page:
[19750.075652] tb kernel: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x15f230
[19750.075703] tb kernel: head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[19750.075727] tb kernel: flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
[19750.075759] tb kernel: page_type: f5(slab)
[19750.075794] tb kernel: raw: 0017ffffc0000040 ffff888100043180 dead000000000122 0000000000000000
[19750.075809] tb kernel: raw: 0000000000000000 0000000000020002 00000000f5000000 0000000000000000
[19750.075836] tb kernel: head: 0017ffffc0000040 ffff888100043180 dead000000000122 0000000000000000
[19750.075859] tb kernel: head: 0000000000000000 0000000000020002 00000000f5000000 0000000000000000
[19750.075874] tb kernel: head: 0017ffffc0000003 ffffea00057c8c01 ffffffffffffffff 0000000000000000
[19750.075890] tb kernel: head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
[19750.075900] tb kernel: page dumped because: kasan: bad access detected
[19750.075915] tb kernel:
[19750.075940] tb kernel: Memory state around the buggy address:
[19750.075982] tb kernel:  ffff88815f22ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[19750.075997] tb kernel:  ffff88815f230000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[19750.076050] tb kernel: >ffff88815f230080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[19750.076085] tb kernel:                                      ^
[19750.076101] tb kernel:  ffff88815f230100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[19750.076125] tb kernel:  ffff88815f230180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[19750.076132] tb kernel: ==================================================================
[19750.076148] tb kernel: Disabling lock debugging due to kernel taint

In another boot, I met wild-memory-access in event_property_validate： wild-memory-access

After that, the laptop screen was frozen, and external displays went black.

I am too busy to decode the stacktraces immediately. Will decode them later today.

Here are the decoded stacktraces.

freed-by-drm_client_modeset_probe-decoded.txt

wild-memory-access-decoded.txt

mentioned in commit nouveau@bac7b8b1

mentioned in commit nouveau@93d70106

mentioned in commit nouveau@378b361e

I got a boot that can trigger SUAF, so I triggered it by disabling/reenabling a monitor (via KDE Plasma 6 systemsettings) or unplugging/replugging an MST dock. I managed to learn and use bpftrace in the hope of revealing more details, and here is my discovery.

The display configuration is eDP-1:3072x1920@120 DP-7:1920x1080@75 DP-8:2560x1440@75 DP-9:1920x1080@60, while the latter three monitors were connected via an MST dock. DP-7 was an HDMI monitor, DP-8 was a DP monitor, and DP-9 was a DP dummy plug (used for Sunshine+Moonlight streaming so that other monitors can be disabled to save energy). The SUAF can be triggered with or without the dummy plug. When the dummy plug is plugged in, the only visible side effect is seeing [drm] MST_DSC Send DSC enable/disable to synaptics in dmesg.

Disabling/reenabling a monitor

8_disable_enable-decoded.txt

SUAF was triggered on both disabling and reenabling DP-9. This can be triggered by any monitor in my previous tests. I simply didn't want to see my windows messed up so I chose the dummy plug to trigger the SUAF.

The SUAF address was:

ffff88816dcd40b0

And let's check aconnector[]:

.aconnector = [0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xffff88816dcd4000,0xffff888203ca0000,0xffff88818f48c000,0x0,...]
... or ...
.aconnector = [0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xffff88816dcd4000,0xffff88818f488000,0xffff88818f48c000,0x0,...]

Not sure why the indexes to place these pointers were so strange.

Noting that the bpftrace output had some delay before it could be printed, and the timestamp may not be completely accurate. Thus, some bpftrace output could appear in a strange position.

Unplugging/replugging an MST dock

9_undock_dock-decoded.txt

SUAF was triggered only on replugging. Unplugging can also trigger SUAF in my other test (plz let me know if you need its log).

The SUAF addresses were:

ffff8881e7c100b0
ffff88818f48c0b0
ffff88818f4880b0

Noting that the test was done right after the above test, and the last two addresses appeared before (but the first one was not, why?).

And let's check aconnector[]:

.aconnector = [0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xffff8881e7c10000,0xffff88818f488000,0xffff88818f48c000,0x0,...]
... or ...
.aconnector = [0xffff888180b58000,0x0,...]

slab-use-after-free in event_property_validate (amdgpu_dm_hdcp.c)

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

6.13.2-xanmod1

1

2 (stacktrace decoded)

6.14-rc4 (stacktrace decoded)

Designs

Child items ...

Activity

6.14-rc6 + https://lore.kernel.org/amd-gfx/20250305051402.1550046-19-chiahsuan.chung@amd.com/T/#u

Disabling/reenabling a monitor

Unplugging/replugging an MST dock

Admin message

Admin message

slab-use-after-free in event_property_validate (amdgpu_dm_hdcp.c)

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

6.13.2-xanmod1

1

2 (stacktrace decoded)

6.14-rc4 (stacktrace decoded)

Activity

6.14-rc6 + https://lore.kernel.org/amd-gfx/20250305051402.1550046-19-chiahsuan.chung@amd.com/T/#u

Disabling/reenabling a monitor

Unplugging/replugging an MST dock