Re: kernel NULL pointer dereference in quirk_clear_strap_no_soft_reset_dev2_f0 -> amd_smn_read

[Mario Limonciello <mario.limonciello@amd.com>]

On 6/5/26 12:45, Marek Marczykowski-Górecki wrote:
> On Fri, Jun 05, 2026 at 12:36:29PM -0500, Mario Limonciello wrote:
>>
>>
>> On 6/5/26 12:34, Marek Marczykowski-Górecki wrote:
>>> On Mon, Jan 12, 2026 at 08:47:50PM -0600, Mario Limonciello wrote:
>>>>
>>>>
>>>> On 1/12/2026 7:01 PM, Marek Marczykowski-Górecki wrote:
>>>>> Hi,
>>>>>
>>>>> I've got a report that kernel 6.17.9 crashes when running a Xen HVM domU
>>>>> with AMD Raphael/Granite Ridge USB controller passed through.
>>>>> It worked correctly in 6.12.59. Between those versions, I don't see any
>>>>> relevant change to quirk_clear_strap_no_soft_reset_dev2_f0() function,
>>>>> but the AMD node driver did got some changes, so my guess is one of them
>>>>> is to blame. I know the good-bad range is huge, but there aren't that
>>>>> many changes to the AMD node driver in this range.
>>>>
>>>> Is this perhaps a case that only the USB controller was passed through but
>>>> that the root controller wasn't?  That would lead to a case that
>>>> amd_smn_init() was never called and thus amd_roots was not initialized
>>>> properly.
>>>>
>>>> So it would be a NULL pointer deref.  If that's correct, something like this
>>>> should work to avoid it.
>>>>
>>>> diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c
>>>> index 3d0a4768d603c..894823b444d47 100644
>>>> --- a/arch/x86/kernel/amd_node.c
>>>> +++ b/arch/x86/kernel/amd_node.c
>>>> @@ -91,6 +91,11 @@ static int __amd_smn_rw(u8 i_off, u8 d_off, u16 node, u32
>>>> address, u32 *value, b
>>>>           if (node >= amd_num_nodes())
>>>>                   return err;
>>>>
>>>> +       if (!amd_roots) {
>>>> +               pr_warn("AMD SMN roots not initialized.\n");
>>>> +               return err;
>>>> +       }
>>>> +
>>>>           root = amd_roots[node];
>>>>           if (!root)
>>>>                   return err;
>>>
>>> Thanks, I finally got confirmation from affected user that this patch
>>> fixes the issue. From what I understand, adbf61cc47cb ("x86/acpi/boot: Correct
>>> acpi_is_processor_usable() check again") was not enough.
>>>
>>>>> Original report at (with full kernel log etc): https://forum.qubes-os.org/t/yet-another-usb-keyboard-thread/38355/8
>>>
>>
>> There's another patch being discussed.  Could this help?
>>
>> https://lore.kernel.org/all/20260602184823.GKah8ld2QJLm28xoa9@fat_crate.local/
> 
> Especially with 2/2 patch there, yes, looks like it would help too.
> 

Can you try Boris' inline proposal specifically?