[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1gP=3N1z3=2sZpDyz6LHJohNhPAet+Xm-Q26jKY9KRjw@mail.gmail.com>
Date: Tue, 7 Nov 2017 17:03:14 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Richard Henderson <rth@...ddle.net>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>,
y2038 Mailman List <y2038@...ts.linaro.org>,
Deepa Dinamani <deepa.kernel@...il.com>,
"# 3.4.x" <stable@...r.kernel.org>, linux-alpha@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] alpha: osf_sys.c: fix put_tv32 regression
On Tue, Nov 7, 2017 at 4:52 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Tue, Nov 07, 2017 at 03:09:24PM +0100, Arnd Bergmann wrote:
>> There was a typo in the new version of put_tv32() that caused
>> uninitialized stack data to be written back to user space, rather
>> than writing the actual timeval for the emulation of
>> gettimeofday(), wait4(), usleep_thread() and old_adjtimex().
>>
>> This fixes it to write the correct data again.
>
> *blink*
>
> the bug is real, all right, and the fix is correct one, but where
> do you get an infoleak? What it is is a user-triggerable oops -
> just pass it an unmapped address. For anything mapped r/w it's
> simply a no-op - userland data is unchanged.
>
> IOW, the fix is correct, but commit message isn't - it's
>
> "user-triggerable oops and in all cases failed to modify userland timeval32"
>
> not
>
> "uninitialized stack data to be written back to user space"
Ah right, sorry about that. I misread the statement as setting
the temporary structure to itself rather than setting it to the contents
of the user structure.
Do you want to update the description as suggested and forward it,
or should I send a fixed version? I'm about to leave the office for
today, so I'd have to do it tomorrow then.
Arnd
Powered by blists - more mailing lists