Date:   Fri, 17 Dec 2021 12:10:46 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Steven Price <steven.price@arm.com>
Cc:     Rob Herring <robh@kernel.org>, Daniel Vetter <daniel@ffwll.ch>,
        David Airlie <airlied@linux.ie>,
        Tomeu Vizoso <tomeu.vizoso@collabora.com>,
        Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
        Boris Brezillon <boris.brezillon@collabora.com>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/panfrost: Avoid user size passed to kvmalloc()
Message-ID: <20211217091046.GG1978@kadam>
References: <20211216161603.983711-1-steven.price@arm.com>
 <CAL_JsqKZBsJxy8h5EQf0wwfioWS-Kx9i=0cQ7p4FHckEXstGiw@mail.gmail.com>
 <4c564c0d-7702-9dfe-910f-969fe130aba8@arm.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4c564c0d-7702-9dfe-910f-969fe130aba8@arm.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?M8SeSdSzrsXDJSa+92A0b6X2jwvtN5tB7K4HTPiyTvhmQdYXbtj8kxZInfmP?=
 =?us-ascii?Q?+6pUtOZTWkFRyQyqy6f9K3f92mbirUJwey6hZI8Q4merjA+N8Ldagvcq25he?=
 =?us-ascii?Q?k5pWW5tdSCXtIVjoXtUnW8cUnN4nBPsO5tQnzCxHSxztJBid50y2WbL+6/cM?=
 =?us-ascii?Q?n8oNox+esMLO8lSC4moDDGDvLTvqEwAqGfAZUAERmhuX7WTXkrEPoQfUnjEb?=
 =?us-ascii?Q?IfCHJg74PGgGh1UvcpxlMcED5oTMAMDOfHh9dw9yf1LQL8S1VU9wDaHAemFx?=
 =?us-ascii?Q?S+lxLygtDPd2C3+oyIuhpa4TK+JKfFVirTZIgN2ubatOv6a9dKZkZibI/zvZ?=
 =?us-ascii?Q?n4puH9klp5ohz0iL/WnfgaLU605imSQEWxRUzIXA/FJA1zWaccdkkpLH029I?=
 =?us-ascii?Q?PL4UljENCa+yvLVu0psL+xYsYpStseeVQ6zyAagkCVlzdjK2ZH24blcJNL/o?=
 =?us-ascii?Q?i/f/e+CUcFWbIE9jXxuMsN+cmSFhYDSB597e2PbBTslSXaN2qgnFs+KMar2B?=
 =?us-ascii?Q?/X2lzjbPiog/u2CL3Ue0TMfYIS1zUkjfpEyGl9tA+HUb1MWzoEEUpWjKSJv1?=
 =?us-ascii?Q?qiIUt5Z4RdwHPGxrfzL3O2XObPlUKvSAJEwm+NGDjNIYrCX+UaIHvlmfmIsY?=
 =?us-ascii?Q?tpBXT9jlaeiFppivSLGkzCVpqCZqQjesBtVYPvMt4AoZe4W5sG8R0jrijypG?=
 =?us-ascii?Q?LYV8vQnHSD33gQluDPH8gnqanzL6M9zbcQ1tn9xfQDVH3OHSetWLDBIO5mJ/?=
 =?us-ascii?Q?5u6xTY+h1GQy2NS3sBBzWzNkQwJdK9ytA355VoLj2jHJUpCYRMDD24qWAkie?=
 =?us-ascii?Q?srbCwt6k8DEkJEMG1wjYbZ6SKOYuXQMgNbDr9ntRgOAp6j36L8XcpRa14krQ?=
 =?us-ascii?Q?x8vwl+hzHIQ9EKvIdYMitxHNkoRKmp2J1XtJSx5oXdZKPs2XlAXBO/QI9/CB?=
 =?us-ascii?Q?PJO0MjMb2r64uuiRwE4O5nUa/JKsD9cdWFWmvBR4YRSSZncBkWEMeSPzW1ZB?=
 =?us-ascii?Q?vlNx/i8l/7m3BfjPSxAZtnD8FJVgNpCja5ZAGL8Vxfb/RsnZwoYyIpbo5YEZ?=
 =?us-ascii?Q?DkPuhJwjUvVTH5nc/1SZrvrDfCotyPrHyO9F/4WZFt5x1nAhuWY6hhEfm5bX?=
 =?us-ascii?Q?8W2mT0QCqekmq83iaUcLtDHfucHndzddTOCYR8R/34FK7DM08XhO/PgEnAK/?=
 =?us-ascii?Q?l3DqpP3h0itxl6q2cuYdaCFpltOsIzPbUf7thrOppRt7NvssiFox8wsicDkB?=
 =?us-ascii?Q?W568Zlo3RveI9Kw3ZagNbzWkA0LawG5l9zRN8sDo2rR+On7UZvvVTX9f3sDR?=
 =?us-ascii?Q?VM4IWunUdJoa1XlGhenhQk6QMdSx+Lv/kBOlvROMFCg6f6pGYubx2g7wsO+T?=
 =?us-ascii?Q?BnEoXNdYArxYC0LzqYdcjeuchsYuljvEBvUQTXhstGZiHJtHVmQJj4xNe6HK?=
 =?us-ascii?Q?CPlPdWSge1lwd0qxBSrQQBg0nERTCFpn1ojWfnTmd4x154bYYeTU/hEK/cNe?=
 =?us-ascii?Q?HteZ5bzMyIM5IZHuCFB/YbnpD+U90u8AirdI4HRYU0gjD1eWzQY61FJsfZDe?=
 =?us-ascii?Q?YxUuP0XwT2P+lmtnGHXAIv3wk1IBB1LXXosUwpSj7o3hh8Sgp/QaaOxcsHvq?=
 =?us-ascii?Q?epxULpY2MW6zvv6aO/KldbI8P4BnYb2K3Pn6gLjN/CbI9zAlegoM2hjHD2KI?=
 =?us-ascii?Q?TlADqMe9wzIiRV7ySl9f9sAKDPU=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 000e5766-4c84-4b71-2c39-08d9c13d29ea
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2365.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2021 09:11:09.4581
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gsBv0wMYAgvuJv+rSR0S6dqbi0TtTn3PVtSHaGaQaY+6WSIb27fXhafuhtiJsDlBcPzeYNcIEkDuS8nO2jRwDwbOtAc+bIoqIBas1zRpwf8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1565
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10200 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0
 malwarescore=0 bulkscore=0 spamscore=0 mlxlogscore=999 mlxscore=0
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2110150000 definitions=main-2112170052
X-Proofpoint-ORIG-GUID: AxahgGY0dLU50MRmt2OM9RrgBNjvK5DH
X-Proofpoint-GUID: AxahgGY0dLU50MRmt2OM9RrgBNjvK5DH
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Dec 17, 2021 at 08:55:50AM +0000, Steven Price wrote:
> However this one is harder to fix without setting an arbitrary cap on
> the number of BOs during a sumbit. I'm not sure how other drivers handle
> this - the ones I've looked at so far all have the same issue. There's
> obviously the list that Dan already sent, but e.g. msm has the same bug
> in msm_gem_submit.c:submit_create() with an amusing bug where the check
> for (sz > SIZE_MAX) will never hit, although the call is to kzalloc() so
> large allocations are going to fail anyway.

sz is u64 and SIZE_MAX is ULONG_MAX so the (sz > SIZE_MAX) condition
does work to prevent an integer overflow on 32bit systems.  But it's not
beautiful.

regards,
dan carpenter