Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4177249pxj; Mon, 21 Jun 2021 15:39:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3H+FnNj+eqnTpVhJsj+/ueWy+iSDGI9KUUx7RMw3hW7ldj6Pt0Z5zxxZjTzetCCdHWIp/ X-Received: by 2002:a92:d6cd:: with SMTP id z13mr363994ilp.175.1624315173879; Mon, 21 Jun 2021 15:39:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624315173; cv=none; d=google.com; s=arc-20160816; b=weZdytWcayYZk6osj26sEWUbzEtYH5DxO0RnakawHPEjD8GoM1CFQsQ9HqXmfFgAGh loDaRhUjv2eblrAZ0vdQjdqMshSf1YrdigSuYP4ElbwAQarWvumih2S1pVzHa+lyeYZU 4SeMXhJgBbkah6rYz4Ly8UnAIta/39nZqjvo6n2QqsVl5tLPjC26nGk4LO/+y0PD/K3z W2+ajJKgT3L458JRD2PyZnfy+Z8yeoI5VMzujfS1IZTz5ZgRL93LEpbuewuG9MP6nbNZ 64XTClypZtBP/5KydQ2ARLbsB3IecaNZolWSp5OZYb5caYggMx7AoD/kiDfdFb4Y/TPm H28w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=5jTTwbPg5aA08kWmM54tNTs/OmEDeM6LKJVdhYuFH14=; b=lUNtqw/X7XTXGvvo2SkYm7waJFsolROy1aytB04uSWmVrTaTCDmsRCHuabkCOtfdIA FDQy/q3hJmbSyJm5BNKMFXlhjhip0ssCaI+3J6xdYCKcHj0rMEGJsX6XIWMBwYO5Snac s9/hfrDDISVoffum+wP9fh67q6fE5Bdhux4S+L8SKMvA3DIdFMlFLFvklOU7pXD5PiKv ZbcLimwScUg5tvI/NnJwMXsI2gkAR5KqEwDbBGKLuy3ozouv+M1kVx0CMj2eYcx/Sf+0 ekMvX2+QdTUW6q4f4B+9zFVD1euqdl/9QnkLJRp+1SfJBBeyogMqJHgzw8D/9njeD5D0 v8Bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HBYIAUjX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w2si19764877iop.49.2021.06.21.15.39.21; Mon, 21 Jun 2021 15:39:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HBYIAUjX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232056AbhFUWk7 (ORCPT + 99 others); Mon, 21 Jun 2021 18:40:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230438AbhFUWk7 (ORCPT ); Mon, 21 Jun 2021 18:40:59 -0400 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A67C4C061574; Mon, 21 Jun 2021 15:38:43 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id b5-20020a17090a9905b029016fc06f6c5bso470803pjp.5; Mon, 21 Jun 2021 15:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5jTTwbPg5aA08kWmM54tNTs/OmEDeM6LKJVdhYuFH14=; b=HBYIAUjX4Mgt1ZnCBVIxrxXOExvlU5RU16L32k9uNAedNlWaX4/eI9Ppgm39VanY/7 RlkmrLuameKM6FzWhahTvGYxIIqHrZ2uIPCmKv1CNUIMzQmh2+QbnnnOmB0rqgm1cxwI 6oICzqEr5ndIHmssKrjHeG11ASnt0mnT8OGRWVH2Jd7M0XtxbGO+Oe39V1qnn/801sUO iulWXLLDCoJTpgo5F/ffSupKzdsq8dVgthXFglTvJm2KJa4yS7QD2K/F7bcUJzSM6YQA /B5qFS1+eN+F1CqusjK5ap4f6q9OCrH8l+o9jgWAwwuVbjRVBhrTh5z6DNlYID7RbD6E KlvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5jTTwbPg5aA08kWmM54tNTs/OmEDeM6LKJVdhYuFH14=; b=SvDoseLbIyXW5EvpD1WK4KaJZVxX1ITKkAa55stHhHl5/8VpdJDbSQtyLWCKKB6Mzq 489PKuJTPy0iKnjy+eF7lMkJJ4ais3KagqTEE9oyZ4EhAUrojzVyAtAn00gvj794uD5K eBow1/aFJiGlICBBagy71wqk4Y5Op5/ctu62qPevntrPiQFrschXjevbTltEn53wvlBH zEfPVviO/D9w63pzgkEls1PqYnzUJ3I1ik3EZV1VWZkE9UkSUubXWkX0HZUtiPM3MpE/ dS7SXAmO1XXykPhithEfWQs2yLWtVIHtjqxvjsd/1Yj8EjPiiBKCTeKPyIeqBeAXzknH dMmw== X-Gm-Message-State: AOAM533hskKnsOq8Pd8hqSUxR2OIcDrLCQf71Ba2UWabqPsUDUamfVgG sxSOIj+LOb+SgtDhat/108A= X-Received: by 2002:a17:90a:8589:: with SMTP id m9mr520145pjn.168.1624315123034; Mon, 21 Jun 2021 15:38:43 -0700 (PDT) Received: from google.com ([2620:15c:202:201:a276:c46e:ab3a:dce2]) by smtp.gmail.com with ESMTPSA id l5sm15871455pff.20.2021.06.21.15.38.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Jun 2021 15:38:42 -0700 (PDT) Date: Mon, 21 Jun 2021 15:38:39 -0700 From: Dmitry Torokhov To: Alexander Larkin Cc: torvalds@linux-foundation.org, dan.carpenter@oracle.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, murray.mcallister@gmail.com, security@kernel.org Subject: Re: [PATCH] Input: joydev - prevent potential write out of bounds in ioctl Message-ID: References: <20210621213215.1698347-1-avlarkin82@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210621213215.1698347-1-avlarkin82@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alexander, On Tue, Jun 22, 2021 at 12:32:15AM +0300, Alexander Larkin wrote: > I'm still studying "git send-email", so the first intro part of prev msg deleted, sorry, again: > > Continuying my previous message, the JSIOCGBTNMAP always returns 1024 return code, > but not "amount of buttons" like I said before > (that is probably the size of the keymap that is _u16 keymap[KEY_MAX - BTN_MISC + 1] ). > Is it correct? > Reading the line of kernel joydev.c > 579 len = min_t(size_t, _IOC_SIZE(cmd), sizeof(joydev->keypam)), > , why the min is always sizeof(joydev->keypam) ? > If I try to call from the userspace > ioctl(fd, JSIOCGBTNMAP, buttons) > where the buttons is "__u16 buttons[5]", then still I get 1024. > > Also I did userspace test (that shows how kernel overwrites (out of array bound) the userspace): > 1. The buttons is "__u16 buttons[5]" in userspace, > 2. buttons[5] = 1; > 3. ioctl(fd, JSIOCGBTNMAP, buttons) > 4. printf("new %i\n", buttons[5]), > and the output is "new 0", so the value is being overwritten by kernel (so 1024 bytes copied > to 10 bytes buffer). > > It looks like I don't understand what is the expected value of the _IOC_SIZE(cmd), > why not 10 for this read ioctl example? Is it possible to make this ioctl safe, so > it doesn't copy more data than user can handle? The definition of JSIOCGBTNMAP is: #define JSIOCGBTNMAP _IOR('j', 0x34, __u16[KEY_MAX - BTN_MISC + 1]) so the size is encoded in the definition and userspace is supposed to supply buffer of appropriate size. In your examples you are essentially are lying to the kernel and say that the buffer size is KEY_MAX - BTN_MISC + 1 words while in reality you only supply 10 bytes (5 words). Maybe we should have defined (long time ago) #define JSIOCGBTNMAP_LEN(len) _IOC(_IOC_READ, 'j', 0x43, len) to allow userspace better control over the buffer, but I consider joydev interface obsolete and all new clients should be using evdev to get events from input devices. so I am not sure if there is any benefit in fixing joydev ioctls. Thanks. -- Dmitry