NACK/Cmnt: [SRU][J][PATCH 0/1] CVE-2025-37861

[Edoardo Canepa]

Rejected for the following reasons:

The de-indexing is right and the refcounting is balanced, but on this
tree the patch introduces a NULL dereference in event_property_update()
on the same hotplug paths the CVE is about.

event_property_update() here opens with:

     struct amdgpu_dm_connector *aconnector = hdcp_work->aconnector;
     struct drm_device *dev = hdcp_work->aconnector->base.dev;
     long ret;

     drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
     mutex_lock(&hdcp_work->mutex);

Two unlocked loads of the field, and the second dereferences it with
no NULL check. Upstream survives this only because its
event_property_update() iterates the per-connector array and does
"if (!aconnector) continue;". That guard predates d4673f3c3b3d and the
commit does not touch the function, so de-indexing the array here
inherits none of the protection.

Before the patch NULL was unreachable there by construction:
hdcp_w->aconnector was only ever assigned a connector, never cleared -
that stale pointer is exactly what the CVE is about. After the patch
both hdcp_remove_display() and hdcp_reset_display() store NULL.

The window is not exotic. property_update_work is scheduled from one
place, event_property_validate(), which tests aconnector for NULL
before taking hdcp_work->mutex and schedules the work under it.
Between that schedule and the worker running, two paths can take the
mutex and clear the field: hdcp_reset_display(), called from
amdgpu_dm.c:3150 on HPD IRQ and from amdgpu_dm_atomic_commit_tail() at
amdgpu_dm.c:9826, and hdcp_remove_display(), called from
update_config() on every dpms_off. Those are the plug and unplug paths
this CVE is about, so the patch trades a use-after-free for a NULL
pointer oops in the same code.

The fix is small. Load the field once and test it before either lock,
which also removes the double load:

     struct amdgpu_dm_connector *aconnector =
         READ_ONCE(hdcp_work->aconnector);
     struct drm_device *dev;

     if (!aconnector)
         return;
     dev = aconnector->base.dev;

Testing under hdcp_work->mutex would be closer to upstream but needs
more care: dev is needed for the drm_modeset_lock() that is taken
first, so the check cannot simply move inside without reordering the
locks. Either way it belongs in this patch, and the deviation should be
noted in [Fix], since it is a hunk upstream does not have.

On 9/10/26 03:59, Cengiz Can via kernel-team wrote:
> https://ubuntu.com/security/CVE-2025-37861
>
> [ Impact ]
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue
>
> When the task management thread processes reply queues while the reset thread
> resets them, the task management thread accesses an invalid queue ID (0xFFFF),
> set by the reset thread, which points to unallocated memory, causing a crash.
>
> Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O,
> and admin threads. Before a reset, the reset handler sets this flag to block
> I/O and admin processing threads. If any thread bypasses the initial check, the
> reset thread waits up to 10 seconds for processing to finish. If the wait
> exceeds 10 seconds, the controller is marked as unrecoverable.
>
> [ Fix ]
>
> jammy/linux: backported from f195fc060c73
>
> [ Test Plan ]
>
> Build and boot tested.
>
> [ Where Problems Could Occur ]
>
> A regression would only surface on systems using the mpi3mr driver, which
> drives Broadcom MPI 3.0 storage controllers (SAS/SATA/NVMe host bus adapters
> and RAID controllers); the risk is highest during controller reset or task
> management events, where the added synchronization flag could in theory stall
> I/O or admin processing or, if the 10 second wait elapses, mark a controller
> unrecoverable. Systems without such Broadcom controllers do not load this
> driver and are unaffected.
>
> [ Other Info ]
>
> Kybele flow-v11-25-ga27c0fa6. Reference: 57598f19/v1
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260915/1470632a/attachment.sig>