On Wed, Oct 16, 2013 at 09:49:02AM +0100, Chris Wilson wrote:
> Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting
> the 4 bytes beyond the end of its structure with a 32-bit userspace
> running on a 64-bit kernel. This is due to the padding gcc inserts as
> the drm_mode_get_connector struct includes a u64 and its size is not a
> natural multiple of u64s.
>
> 64-bit kernel:
>
> sizeof(drm_mode_get_connector)=80, alignof=8
> sizeof(drm_mode_get_encoder)=20, alignof=4
> sizeof(drm_mode_modeinfo)=68, alignof=4
>
> 32-bit userspace:
>
> sizeof(drm_mode_get_connector)=76, alignof=4
> sizeof(drm_mode_get_encoder)=20, alignof=4
> sizeof(drm_mode_modeinfo)=68, alignof=4
>
> Fortuituously we can insert explicit padding to the tail of our
> structures without breaking ABI.
>
> Reported-by: Pavel Roskin <proski@xxxxxxx>
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Dave Airlie <airlied@xxxxxxxxxx>
> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
> Cc: stable@xxxxxxxxxxxxxxx
Hmm. But that only fixes things if you recompile the 32bit userland
code.
We could also fix old 32bit userland by adopting the same kind of size
handling that we use for driver specific ioctls. The code is already
there, we just need to set asize and usize appropriately.
> ---
> include/uapi/drm/drm_mode.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 550811712f78..28acbaf4a81e 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -223,6 +223,8 @@ struct drm_mode_get_connector {
> __u32 connection;
> __u32 mm_width, mm_height; /**< HxW in millimeters */
> __u32 subpixel;
> +
> + __u32 pad;
> };
>
> #define DRM_MODE_PROP_PENDING (1<<0)
> --
> 1.8.4.rc3
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html