Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp629349imm; Thu, 13 Sep 2018 05:28:55 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaNd1k55dcUgBdxfBqU830Ju4qreYW3//cBJEmc1n8NpwYvzyqSckkJbwVD2AriJFzKIdiU X-Received: by 2002:a63:2c8e:: with SMTP id s136-v6mr7189869pgs.390.1536841735631; Thu, 13 Sep 2018 05:28:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536841735; cv=none; d=google.com; s=arc-20160816; b=MaYJiqtAduc8/IkJgL45C+RWFXF2rD1Ods5qCQdak4GnUzIHp+UaHXDOZ0P29vUxAa XBpyJVq8+ytWq3JRW5KHoSSin1BDibHvm1nmrhL2WPVYy5FJQ+5qK54O+6Nyqgdw3PTt TKyRH8yaMx5R4PGXDO47m7oHDWth9zQXvFESQb3fiHtC1cjt2ZKER8W2Nh5wrt+Tk2lg 21y/R6P69RvGUNbOBMrU8Aj+jT42WpXqS5fCSsrylXK4V5JCb2K75kgprUJ0Dhxn4Zqj S97enzhiLduR9p4K4I7P4d24ioZUl8uEPmB5G7i6fzKk+ymMMleCv06hlYnJKbDblE/u a5Ng== 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 :in-reply-to:references:mime-version; bh=nLbj9lg5eI6XIgh+VfAYWNRoNRHbaP/ZH67mudtqUa0=; b=EeAuoSM/Q0Tof+jEEJ5txq/mtrMoGks+vqMWKPeDk6R8RU6gsc0Eqy6wx8mlqjULR0 6ML9SJmWLLI0+LthxU7QbFJtpOjJwrCq8nugo9vNMGmsITW5Mp7jqY4qKEX24Wl1h3dR mtZn6RqvR/Zc7GyXt+62RLvJBcB5bU+X3lzkiLo4/ZfbAqpvsdciGhYUdQMLn8wl9KOq OxjfSqxRzs+sJxmNnUfOUVehjRoHnZvg3aBbPmXgLTzrK4TNmzD7KPAltp+MumP9I3OM oP3ZuLcI+/LWt0vRt2MotveJ5CVUnbVCxPfslyi1zlQTilos5PbjXHfgmKqo1uRoennU eYiQ== ARC-Authentication-Results: i=1; mx.google.com; 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 i5-v6si3866785pgk.200.2018.09.13.05.28.39; Thu, 13 Sep 2018 05:28:55 -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; 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 S1727150AbeIMRhl (ORCPT + 99 others); Thu, 13 Sep 2018 13:37:41 -0400 Received: from mail-qt0-f194.google.com ([209.85.216.194]:44269 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726741AbeIMRhk (ORCPT ); Thu, 13 Sep 2018 13:37:40 -0400 Received: by mail-qt0-f194.google.com with SMTP id k38-v6so5091139qtk.11; Thu, 13 Sep 2018 05:28:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nLbj9lg5eI6XIgh+VfAYWNRoNRHbaP/ZH67mudtqUa0=; b=UcGrvRjqBtjVX0Qzr8o6wHLetCbwu/x0XazkrQoNd40IQQydbTvU8NKtAhxt/p2UA0 /rPAf7rVCfRL8BizyiCTMaBcXiVLaV9E4dXtPp377dqKmKtaeSxRxfrE3NBZd+nlSXhw 1f7jbP6DKn/5w6IzWLxmaAw3Uq5+NvnnMQj08BsWfcEQMqN2EnAHJEFc6KlVnHQE0XdR vk0dfX4D9JIu4pqfzvcfiv9egqjZwYorvNJIcaj0u9nu9mABsNVIAZw8u/YNpsQUouTM 7qbSd3ZJFgbjZRp22Rz8Zrq1b+kd7rkJWjek61I1RM+utWzskNcN1Jy/2frM6Rla1u0s i3Pw== X-Gm-Message-State: APzg51AwmNZ4Gck81CX2fJ/R2PPRyOn2MJH+9I9mfoQ348R5KJF8LqZX c3hsL8JFIWQ2XB4t5eSiQ/x57ULB/1jh6LZkE22JHA== X-Received: by 2002:aed:3f22:: with SMTP id p31-v6mr4858714qtf.185.1536841704054; Thu, 13 Sep 2018 05:28:24 -0700 (PDT) MIME-Version: 1.0 References: <20180829130308.3504560-1-arnd@arndb.de> In-Reply-To: <20180829130308.3504560-1-arnd@arndb.de> From: Arnd Bergmann Date: Thu, 13 Sep 2018 14:28:08 +0200 Message-ID: Subject: Re: [PATCH net-next 1/3] net: rework SIOCGSTAMP ioctl handling To: Networking , David Miller Cc: linux-arch , y2038 Mailman List , Eric Dumazet , Willem de Bruijn , Linux Kernel Mailing List , linux-hams@vger.kernel.org, Bluez mailing list , linux-can@vger.kernel.org, dccp@vger.kernel.org, linux-wpan@vger.kernel.org, linux-sctp@vger.kernel.org, linux-x25@vger.kernel.org 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 Wed, Aug 29, 2018 at 3:03 PM Arnd Bergmann wrote: > diff --git a/net/core/sock.c b/net/core/sock.c > index 3730eb855095..df17bbfaca27 100644 > --- a/net/core/sock.c > +++ b/net/core/sock.c > @@ -2897,37 +2897,31 @@ bool lock_sock_fast(struct sock *sk) > } > EXPORT_SYMBOL(lock_sock_fast); > > -int sock_get_timestamp(struct sock *sk, struct timeval __user *userstamp) > +int sock_gettstamp(struct socket *sock, void __user *userstamp, > + bool timeval, bool time32) > { > - struct timeval tv; > - > - sock_enable_timestamp(sk, SOCK_TIMESTAMP); > - tv = ktime_to_timeval(sk->sk_stamp); > - if (tv.tv_sec == -1) > - return -ENOENT; > - if (tv.tv_sec == 0) { > - sk->sk_stamp = ktime_get_real(); > - tv = ktime_to_timeval(sk->sk_stamp); > - } > - return copy_to_user(userstamp, &tv, sizeof(tv)) ? -EFAULT : 0; > -} > -EXPORT_SYMBOL(sock_get_timestamp); As I just learned, sparc64 uses a 32-bit suseconds_t, so this function always leaked 32 bits of kernel stack data by copying the padding bytes of 'tv' into user space. Linux-4.11 and higher could avoid that with CONFIG_GCC_PLUGIN_STRUCTLEAK, but older kernels have been affected since socket timestamps were first added. The same thing is probably true of many other interfaces that pass a timeval. > -int sock_get_timestampns(struct sock *sk, struct timespec __user *userstamp) > -{ > - struct timespec ts; > + struct sock *sk = sock->sk; > + struct timespec64 ts; > > sock_enable_timestamp(sk, SOCK_TIMESTAMP); > - ts = ktime_to_timespec(sk->sk_stamp); > + ts = ktime_to_timespec64(sk->sk_stamp); > if (ts.tv_sec == -1) > return -ENOENT; > if (ts.tv_sec == 0) { > sk->sk_stamp = ktime_get_real(); > - ts = ktime_to_timespec(sk->sk_stamp); > + ts = ktime_to_timespec64(sk->sk_stamp); > } > - return copy_to_user(userstamp, &ts, sizeof(ts)) ? -EFAULT : 0; > + > + if (timeval) > + ts.tv_nsec /= 1000; > +#ifdef CONFIG_COMPAT_32BIT_TIME > + if (time32) > + return put_old_timespec32(&ts, userstamp); > +#endif > + > + return put_timespec64(&ts, userstamp); > } My new implementation is worse here: it no longer leaks stack data, but since we now write a big-endian 64-bit microseconds value, the microseconds are in the wrong place and will be interpreted as zero by user space... I'll also have to revisit a few other similar patches I did for y2038, to figure out what they should do on sparc64. Arnd