linux-kernel - [PATCH 0/2 RESEND] Mitigate race condition problems when unbinding DRM driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220311093406.4068019-1-ricardo.canuelo@collabora.com>
Date:   Fri, 11 Mar 2022 10:34:04 +0100
From:   Ricardo Cañuelo <ricardo.canuelo@...labora.com>
To:     dri-devel@...ts.freedesktop.org
Cc:     linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        kernel@...labora.com, andrzej.hajda@...el.com,
        narmstrong@...libre.com, maarten.lankhorst@...ux.intel.com,
        mripard@...nel.org
Subject: [PATCH 0/2 RESEND] Mitigate race condition problems when unbinding DRM driver

Hi all,

I'm sending these patches to try to improve the current situation for a
particular corner case (DRM driver unbinding).

I could reproduce a specific race condition during the unbinding of the
mediatek-drm driver that caused an invalid memory address. The race
condition is triggered by a userspace event (gnome-shell requesting a
DRM GET_CONNECTOR ioctl) while the encoders and drivers are in the
process of being disabled.

While I tried to mitigate this by making a small change in the
parade-ps8640 driver (for the bridge I'm testing on) and by making a
couple of functions in drm_bridge.c more robust, this is only a symptom
of a larger problem that might not be getting enough attention,
understandably, because this is an unusual corner case.

The scenario looks like this:

<userspace>: unbind mediatek-drm   --------------------+
              |                                        |
           <kernel>                                    |
              |                                        |
             ...                                       |
              |                                       ...
        mtk_dsi_unbind                                 |
              |                                        |
              `- drm_encoder_cleanup                   v
              |   |                                 gnome-shell
             ...  `- drm_bridge_detach *<------ ioctl (GET_CONNECTOR)
                                                   |
                                                <kernel>
                                                   |
                                                  ...
                                                   |
                                                   |
                                      ps8640_bridge_get_edid
                                         |
                                          `drm_bridge_chain_post_disable

which causes drm_bridge_chain_post_disable() to walk the bridge chain
after the bridge has already been detached and removed from the list. I
guess a more radical and subsystem-wide solution would be to not allow
or to block certain ioctl calls once the driver has started to unbind,
but I'd like to hear your opinion on this.

This was tested on an Acer Chromebook R13 (Elm, MT8173) running Debian
Sid, the command that triggers the race condition is

echo mediatek-drm.12.auto > /sys/bus/platform/drivers/mediatek-drm/unbind

Cheers,
Ricardo

Ricardo Cañuelo (2):
  drm/bridge: parade-ps8640: avoid race condition on driver unbinding
  drm/bridge: Add extra checks in pre_enable and post_enable

 drivers/gpu/drm/bridge/parade-ps8640.c | 6 +++---
 drivers/gpu/drm/drm_bridge.c           | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

--
2.25.1