From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (unknown [192.198.163.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C46C374E79 for ; Tue, 3 Mar 2026 14:53:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772549618; cv=none; b=C1ihMKQDWMtC9ZbstkQEnb65ygmRrznLC859N1RQIzHNnwtDZKYtpGoeyuspNsufJrqBg6dcm+5MSBwk6ouCHWasQ+XxC5MoqloZP5zcIPKt1r/SYSz3+DOtaMZYPxLDbd02p2QOYpyS1hk5BMCbMt0d5UUVZhIjY16DaiGnbKw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772549618; c=relaxed/simple; bh=1nlvIYv5euBJa0bVyCRXrzDZb9Y+ArrL9TcHZkINM2Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nwrhJmPrglGB/ZIuIg6SSuV9SHEoffHbcvY6LIGQNmwi5KegQMN2wZVYbW4XlY4fUIR7lhmXeUerkH4BGaU+MNcc9pQlbeXt2FAHbYo/sjCnrdQpB0bxJXro6xqg7oP+x6bf3fbJjddMyzCEBwMP9FuLmBx0v6aGAsSdTN5x5XY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=O57vCkvS; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="O57vCkvS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772549599; x=1804085599; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=1nlvIYv5euBJa0bVyCRXrzDZb9Y+ArrL9TcHZkINM2Q=; b=O57vCkvScHRRAbcGNrozL2yUZQj1yVu1d5JajwkgmxpNGUQz68USZovM 4WmgdQ5lrlRdJVRTszBJnRYdYbK8LkAp3cOq2KP7thDHC0MG79kCcckr4 OO+JEb/EfiY9lOZlzpqSZFej4yviO5SdDLA+NpqEIqZShODfsCQNWWSEV 3ztQmM/B+PxD2CSfjwICz6DnMEXdL3ZnvhBaBKrSx+/i/e+8O4UyMfC9v ypcehnmbEDTeFbWfoUw3R5cL1zpxERl04oZ0KCfh31nIUtcKafAAsKFi8 o6X82v4JyI3g+2mxz+rDa4jvYLcO/FvEZwkdshQ6lmAuhqOsyzxqDTBmg A==; X-CSE-ConnectionGUID: 1zMdqRNOSNKXgu1N710LPw== X-CSE-MsgGUID: +52vvW3+SA2EJHESwOkM2g== X-IronPort-AV: E=McAfee;i="6800,10657,11718"; a="91159150" X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="91159150" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 06:53:09 -0800 X-CSE-ConnectionGUID: /lkztj10RNer0pf/lSSpkQ== X-CSE-MsgGUID: 5yHmc7wZQu684QHMtFrPyQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="241031263" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO [10.245.245.25]) ([10.245.245.25]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 06:53:07 -0800 Message-ID: Date: Tue, 3 Mar 2026 15:53:05 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drm/syncobj: Fix handle <-> fd ioctls with dirty stack To: Julian Orth , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , =?UTF-8?Q?Christian_K=C3=B6nig?= , Dmitry Osipenko , Rob Clark Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20260301-point-v1-1-21fc5fd98614@gmail.com> Content-Language: en-US From: Maarten Lankhorst In-Reply-To: <20260301-point-v1-1-21fc5fd98614@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hey, Den 2026-03-01 kl. 13:34, skrev Julian Orth: > Consider the following application: > > #include > #include > #include > #include > > int main(void) { > int fd = open("/dev/dri/renderD128", O_RDWR); > struct drm_syncobj_create arg1; > ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &arg1); > struct drm_syncobj_handle arg2; > memset(&arg2, 1, sizeof(arg2)); // simulate dirty stack > arg2.handle = arg1.handle; > arg2.flags = 0; > arg2.fd = 0; > arg2.pad = 0; > // arg2.point = 0; // userspace is required to set point to 0 > ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &arg2); > } > > The last ioctl returns EINVAL because args->point is not 0. However, > userspace developed against older kernel versions is not aware of the > new point field and might therefore not initialize it. > > The correct check would be > > if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_TIMELINE) > return -EINVAL; > > However, there might already be userspace that relies on this not > returning an error as long as point == 0. Therefore use the more lenient > check. > > Fixes: c2d3a7300695 ("drm/syncobj: Extend EXPORT_SYNC_FILE for timeline syncobjs") > Signed-off-by: Julian Orth I'm not convinced this is the correct fix. Userspace built before the change had the old size for drm_syncobj_create, the size is encoded into the ioctl, and zero extended as needed. See drivers/gpu/drm/drm_ioctl.c: out_size = in_size = _IOC_SIZE(cmd); ... if (ksize > in_size) memset(kdata + in_size, 0, ksize - in_size); This is a bug in a newly built app, and should be handled by explicitly zeroing the entire struct or using named initializers, and only setting specific members as required. In particular, apps built before the change will never encounter this bug. Kind regards, ~Maarten Lankhorst