[lkml]   [2018]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BUG: GPF in non-whitelisted uaccess (non-canonical address?)
On Wed, Nov 14, 2018 at 4:20 AM, David Herrmann <> wrote:
> Hey
> On Wed, Nov 14, 2018 at 1:25 AM syzbot
> <> wrote:
>> syzbot has found a reproducer for the following crash on:
>> HEAD commit: ccda4af0f4b9 Linux 4.20-rc2
>> git tree: upstream
>> console output:
>> kernel config:
>> dashboard link:
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro:
>> C reproducer:
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by:
> [...]
>> BUG: GPF in non-whitelisted uaccess (non-canonical address?)
> This uses sendpage(2) to feed data from a file into a uhid chardev.
> The default behavior of the kernel is to create a temporary pipe, then
> splice from the file into the pipe, and then splice again from the
> pipe into uhid.
> The kernel provides default implementations for splicing between files
> and any other file. The default implementation of `.splice_write()`
> uses kmap() to map the page from the pipe and then uses the
> __kernel_write() (which uses .f_op->write()) to push the data into the
> target file. The problem is, __kernel_write() sets the address-space
> to KERNEL_DS `set_fs(get_ds())`, thus granting the UHID request access
> to kernel memory.
> I see several ways to fix that, the most simple solution is to simply
> prevent splice/sendpage on uhid (by setting f_op.splice_write to a
> dummy). Alternatively, we can implement a proper splice helper that
> takes the page directly, rather than through the __kernel_write()
> default implementation.

also +dtor for uhid

 \ /
  Last update: 2018-11-14 17:53    [W:0.131 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site