Received: by 10.213.65.68 with SMTP id h4csp99449imn; Thu, 15 Mar 2018 18:38:15 -0700 (PDT) X-Google-Smtp-Source: AG47ELtpAlz9acW7uvkiYat2uUg3yj0obkBnkN20DZKYGuQoNXCd8zK+SFXiom2womNW57Yg3ZEf X-Received: by 10.98.13.211 with SMTP id 80mr11431pfn.69.1521164295404; Thu, 15 Mar 2018 18:38:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521164295; cv=none; d=google.com; s=arc-20160816; b=RJwmOBSIEznBTODGdr9Cs+HfC9zzNhzB6Cjv5ex9oiQ1UfWxbBEuFVx+Z2bGOofyjR lpNGYBtqcpdVsDFR/DOeTigoG5Nq5IOVFsfijisdqHAS5adFfQvE58tjYDtF2rUlspL7 vP0dt8og/kVFO5pJrSrqYWtWqGzVdNFwdc0ghUR5ukDKlN/GftHrLTB5hAsmZobogkb1 iaMtNu7dyMHMA3EdLjMY/xkFNwnaQJK5tsW1KYp19+N/kkPNFJ9kU/2pMMNnYoN3ASj/ VBBF0OmmlezDtOrym4ml3ATTDvqx+rSPNreN8Ee5rQTh6ACCB+vwM869/evdwgLeF8qN Vprw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=8WtkZHVRDBFzeTTFbBcVFo+4NEww/TdD+Nn0QJOY6Po=; b=n5EsKpfv37QJx35k7MXk2FK6bAnj+jKpStNJS1p08gJoUtoEwU1SF+HFiXzXE9cWxW nDB9W/Xk+yNDiexv88L+N1WOu0rQ9lo0g/TSG72Md7nzRZvi4J0rdz4lAjTYt3rbUiAU Pyzkq01PVzOJDmnDpQpHmO0z6f5HRwnQwnG3J29OMotkDqEyVbmRFn9ZrCSZfSp9QNgf tzZjFh3M1uXyfruQtKyN1Lli/S7wSsf61o9bax4nsfuXtI5hBYWoDri/cVrPk+oskE/2 9i6rNkMH2DKwiazVdmJj4WFUjXH+AMmHnjXFHR+Lh4Be8/CkMzDMzPL7SVkIHVAKw7JR TJ8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=UMPiPPr4; dkim=fail header.i=@linux-foundation.org header.s=google header.b=hi+OG88E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si5145455plu.465.2018.03.15.18.38.01; Thu, 15 Mar 2018 18:38:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=UMPiPPr4; dkim=fail header.i=@linux-foundation.org header.s=google header.b=hi+OG88E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752948AbeCPBfM (ORCPT + 99 others); Thu, 15 Mar 2018 21:35:12 -0400 Received: from mail-io0-f176.google.com ([209.85.223.176]:33785 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751877AbeCPBfL (ORCPT ); Thu, 15 Mar 2018 21:35:11 -0400 Received: by mail-io0-f176.google.com with SMTP id f1so10841367iob.0 for ; Thu, 15 Mar 2018 18:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8WtkZHVRDBFzeTTFbBcVFo+4NEww/TdD+Nn0QJOY6Po=; b=UMPiPPr421IQbsOBAdW/NICwB1kxUUtIlh5nLtu+Ah7UYjoA1gs4VEUc5gzryV2B+n maz4x6tnjH6WXLSXjOKc9fQ2bzB9J9o6C/v9IzjMgrd2E3xrv2VH2V7scf4g1AQ1z1X3 9a+qHhoI4HX7lITOpkepOU7tSY8Kz7UlWMQfOH3+5tFDSQsX1h5yJvogwpgxGSbcUxNI IeM2eRQKLd3ayFHsQ9GpDfbjA6mtkKO1vBEyYLiIPv0WluP/4iEXDjbN2wq2Bwpfc/EH MdPR8YrkiaL/rbVeusfwizawkcfA2CIRcWLBQqGtTn6Ku0GqHgyIgZ+SDgx6/s7p+IVn yPjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8WtkZHVRDBFzeTTFbBcVFo+4NEww/TdD+Nn0QJOY6Po=; b=hi+OG88EnLcZqfmeIjJLkoFtmHm5yrseTjZ6NlD3z5YPJZ6bH5drhoCxfwwRkgVLC4 nuMf6sBosu98IKMg+bVvi05S43hrTW01+3u45c7rUHhKha1KhPTq6rAV7/Vm8mYYgDv8 zRHrVaPNjFkN0kAgCF7S9GpS7Yza/PGvl8ajY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8WtkZHVRDBFzeTTFbBcVFo+4NEww/TdD+Nn0QJOY6Po=; b=cN6zvO/s1OQoMK5BOxmaycnTN8/rkCnPH9rnyCf/aOUCPrks6CcXtGukhwCaOC4GHj 6Sxn5N3w7V1liwV2/0QmhRjgM98lMDlv/cl45TKAfiN4T42jc9Xj2MNn4YSWgqfzFsuX Oq4W/8Rax80ZI7uNqX58dcbFxm1X+GO4cpAxeRm0VkILb4f6+OeFLe+o3vehfaSee8LU nh1RoMChK3VT3FZgL7hyddmm37CrME/+nwgGURKCuPzpcQ13MqHYJJThiBlYjJGgQo6E 6MsURHUm54x/1Ci5wxkmfJKY6F1j56IV5RGA6LMvtw2qnz9aF5JQF4IqNgf+5udbZd4y JK5g== X-Gm-Message-State: AElRT7FNLJI0cxYz8nmmpPrxhDKonL65HOB6Auzx4zCohUDR2HY8D/ie L3DlMn0L+oF7Sg5eg73dvDdNgiq0y/XCRIjs4og= X-Received: by 10.107.10.219 with SMTP id 88mr11893141iok.259.1521164110745; Thu, 15 Mar 2018 18:35:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.135.221 with HTTP; Thu, 15 Mar 2018 18:35:10 -0700 (PDT) In-Reply-To: <20180316011852.GA5139@jagdpanzerIV> References: <20180308141824.bfk2pr6wmjh4ytdi@pathway.suse.cz> <20180309150153.3sxbbpd6jdn2d5yy@pathway.suse.cz> <20180314140947.rs3b6i5gguzzu5wi@pathway.suse.cz> <20180315075842.GD3628@jagdpanzerIV> <20180315080309.GF3628@jagdpanzerIV> <20180315130117.7c2fb761@vmware.local.home> <20180316011852.GA5139@jagdpanzerIV> From: Linus Torvalds Date: Thu, 15 Mar 2018 18:35:10 -0700 X-Google-Sender-Auth: b3pTiEnrgFPYNabF4yJCJbDEOO4 Message-ID: Subject: Re: [PATCH v3] vsprintf: Prevent crash when dereferencing invalid pointers To: Sergey Senozhatsky Cc: Petr Mladek , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , "Tobin C . Harding" , Joe Perches , Linux Kernel Mailing List , Andrew Morton , Michal Hocko , Sergey Senozhatsky Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 15, 2018 at 6:18 PM, Sergey Senozhatsky wrote: > > Hm, may be sizeof(ptr) still won't suffice. It would be great if we > could always look at spec.field_width, which can be up to 2 * sizeof(void *), > and then just probe_kernel_read(spec.field_width). E.g., %b/%bl prints out a > bitmap, accessing max_t(int, spec.field_width, 0) bits, which is good. But, > for instance, %U (uuid printout) doesn't look at spec.field_width, and reads > in 16 bytes from the given memory address. Then we have ipv4/ipv6, mac, etc. > So I think that checking just 1 byte or sizeof(ptr) is not really enough if > we want to fix vsprintf. What do you think? Honestly, I think it would be better to move the whole logic to the functions that actually do the printout. Then you can do it right, and you don't need to have the strchr() either. There really isn't any commonality between the different versions. field_width is meaningless, since it's about the size of the _printed_ field, not the size in memory. Would it be a few more lines? Yes. But it would also clarify the code and get all the cases right. Look at hex_string() for example, and imagine fetching a byte at a time and just getting the corner cases automatically right. And if you don't care, just do a const char *err = check_pointer_access(ptr); if (err) return string(buf, end, err, spec); at the top of each function that dereferences things. Some of them already have the equivalent of that (the afore-mentioned hex_string: if (ZERO_OR_NULL_PTR(addr)) /* NULL pointer */ return string(buf, end, NULL, spec); and it certainly is neither a lot of extra code, nor subtle or complex to just do that (except using "err = check_pointer_access(ptr);"). Linus