bug: null pointer dereference in Windows hotplug callback (lparam not validated before from_address)

[RockyOmvi]

Describe the bug

In src/packages/buskill/__init__.py, the hotplugCallbackWin function (Windows USB hotplug handler) calls DEV_BROADCAST_HDR.from_address(lparam) without first validating that lparam is a valid pointer. Some WM_DEVICECHANGE subtypes (e.g., DBT_CONFIGCHANGED) pass NULL for lparam, which would cause from_address(0) to access invalid memory and crash the process.

Code reference

src/packages/buskill/__init__.py:175:

dev_broadcast_hdr = DEV_BROADCAST_HDR.from_address(lparam)

The wparam check at line 169 only validates that the event is DBT_DEVICEREMOVECOMPLETE, but does not ensure lparam is non-null before dereferencing.

Expected behavior

Add a null check on lparam before calling from_address:

if lparam == 0:
    return True
dev_broadcast_hdr = DEV_BROADCAST_HDR.from_address(lparam)

Steps to reproduce

1. Run BusKill on Windows
2. Trigger a system-level WM_DEVICECHANGE event that is not device-specific (e.g., changing power source, docking station events)
3. Process crashes

Severity

High — null pointer dereference causing crash on Windows systems.

[maltfield]

@RockyOmvi thanks for the report :)

Trigger a system-level WM_DEVICECHANGE event that is not device-specific (e.g., changing power source, docking station events)

Do you have any way I can reproduce this inside a Windows HVM in Qubes? I don't have a machine that runs Windows on baremetal.

[RockyOmvi]

@maltfield — I found this through static code analysis, not actual reproduction, so the risk may be lower than I initially estimated. Let me clarify:

The WM_DEVICECHANGE callback guard is:

if wparam != DBT_DEVICEREMOVECOMPLETE:
return True
dev_broadcast_hdr = DEV_BROADCAST_HDR.from_address(lparam)
Per Microsoft docs, lparam should be a valid pointer when wparam == DBT_DEVICEREMOVECOMPLETE (0x8004), so under normal conditions this won't crash. The concern is mainly:

Buggy/malicious drivers that send DBT_DEVICEREMOVECOMPLETE with a null lparam
Virtualized/hardware abstraction layer quirks (which you mentioned running in Qubes)
For reproduction, you could write a quick ctypes helper:

import ctypes
user32 = ctypes.windll.user32
HWND_BROADCAST = 0xFFFF
WM_DEVICECHANGE = 0x0219
DBT_DEVICEREMOVECOMPLETE = 0x8004
user32.PostMessageW(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEREMOVECOMPLETE, 0)
That said, I think the more impactful Windows-specific finding is the unbounded blocking send in issue #114 (Kivy thread safety) rather than this edge case — feel free to close this one if it doesn't fit your threat model.