Received: by 10.213.65.68 with SMTP id h4csp1736655imn; Thu, 5 Apr 2018 02:57:47 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+Q/t5dBZZN8K2+/nmc/V6J52QPJ34DvRPDjMKK+rOHS7ZkKlxxEjmXMa9dl0n16f6QxTs7 X-Received: by 10.99.148.17 with SMTP id m17mr14422699pge.140.1522922267585; Thu, 05 Apr 2018 02:57:47 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si5458766pln.656.2018.04.05.02.57.33; Thu, 05 Apr 2018 02:57:47 -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=@natalenko.name header.s=dkim-20170712 header.b=eLVZMsu8; arc=fail (signature failed); 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=natalenko.name Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752448AbeDEJ4M (ORCPT + 99 others); Thu, 5 Apr 2018 05:56:12 -0400 Received: from vulcan.natalenko.name ([104.207.131.136]:45576 "EHLO vulcan.natalenko.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752340AbeDEJ4J (ORCPT ); Thu, 5 Apr 2018 05:56:09 -0400 Received: from mail.natalenko.name (vulcan.natalenko.name [IPv6:fe80::5400:ff:fe0c:dfa0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by vulcan.natalenko.name (Postfix) with ESMTPSA id 181D8332C25; Thu, 5 Apr 2018 11:56:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natalenko.name; s=dkim-20170712; t=1522922167; h=from:sender:reply-to:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:resent-to:resent-cc:resent-from:resent-sender:resent-message-id:in-reply-to:references:list-id:list-owner:list-unsubscribe:list-subscribe:list-post; bh=OV1epDubZ+9Lc43VMkVpI5D/dy9BWeKrxhnkiUGGczY=; b=eLVZMsu8ezrc2baMQ6hjVGbkX8FFfVPM3X/yDCv+VT7qygnEerBAFhQPuePUl9gTbFkqRS Mi/CBWznLf7qy7u/3KkDswKYUAsh2THa883SGclXft66Auov2MAhm2IUWLZy2zFfX2K0Ua ZGcLZlUpgqmFjNjMD7f4anMyYAhNv/U= DMARC-Filter: OpenDMARC Filter v1.3.2 vulcan.natalenko.name 181D8332C25 Authentication-Results: vulcan.natalenko.name; dmarc=fail (p=none dis=none) header.from=natalenko.name MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 05 Apr 2018 11:56:06 +0200 From: Oleksandr Natalenko To: Kees Cook Cc: David Windsor , "James E.J. Bottomley" , "Martin K. Petersen" , linux-scsi@vger.kernel.org, LKML , keescook@google.com Subject: Re: usercopy whitelist woe in scsi_sense_cache In-Reply-To: References: <10360653.ov98egbaqx@natalenko.name> <3265889.eu5sbW8aRz@natalenko.name> Message-ID: <7fc01f67a561ce1fad676fc34c2249e7@natalenko.name> X-Sender: oleksandr@natalenko.name User-Agent: Roundcube Webmail/1.3.5 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=natalenko.name; s=arc-20170712; t=1522922167; h=from:sender:reply-to:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:resent-to:resent-cc:resent-from:resent-sender:resent-message-id:in-reply-to:references:list-id:list-owner:list-unsubscribe:list-subscribe:list-post; bh=OV1epDubZ+9Lc43VMkVpI5D/dy9BWeKrxhnkiUGGczY=; b=1TmiuD7XqTFS3cuDBBsiPSmf16WzCV9xdPPEFAze+3+XCC5ARHBSEMFtlqU/oQJCdP+gZi 6yCKztmOAWMy1AI6DfyWp9JX7XXX3wx/KGJ+ApV4AwigCYI20jCdC2Pzk7TwpjADCc4Z0z JwMOvEsUwB2MfnxDxu3Qkd0438QTYSg= ARC-Seal: i=1; s=arc-20170712; d=natalenko.name; t=1522922167; a=rsa-sha256; cv=none; b=GV0Sg76N/NkKxfgwcKT+iE6veRLbffT0/vZeLxeq2p9eEoxpfHl0EBypqAtABo6CEX9iTAT22mGMnJ0Up3gqreEu0iq85ryE4dztNSZYZNg4i1nLEITlkqWbjXz9Rnj90+ZDfxxdMEKUL6GmEhmhCkEi9ke4ParXBvR3ny1KQqM= ARC-Authentication-Results: i=1; auth=pass smtp.auth=oleksandr@natalenko.name smtp.mailfrom=oleksandr@natalenko.name Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi. 04.04.2018 23:25, Kees Cook wrote: > Thanks for the report! I hope someone more familiar with sg_io() can > help explain the changing buffer offset... :P Also, FYI, I kept the server running with smartctl periodically invoked, and it was still triggering BUGs, however, I consider them to be more or less harmless until the server got stuck with high I/O wait this morning after next smartctl invocation. So, it isn't harmless, it seems… It could be unrelated, of course, since the journal didn't give me any hint (or a stack trace) on what happened, thus I'll monitor how things behave without smartctl too. Regards, Oleksandr