linux-kernel - Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Sep 2016 21:03:20 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     linux-kernel@...r.kernel.org,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        linux-sh@...r.kernel.org, Rich Felker <dalias@...c.org>
Subject: Re: Runtime failure running sh:qemu in -next due to 'sh: fix
 copy_from_user()'

On Fri, Sep 16, 2016 at 12:12:18PM -0700, Guenter Roeck wrote:
> Hi,
> 
> I see the following runtime failure when running a 'sh' image with qemu in -next.
> 
> [ ... ]
> 
> sd 0:0:0:0: [sda] Attached SCSI disk
> EXT2-fs (sda): warning: mounting unchecked fs, running e2fsck is recommended
> VFS: Mounted root (ext2 filesystem) on device 8:0.
> Freeing unused kernel memory: 124K (8c48a000 - 8c4a9000)
> This architecture does not have kernel memory protection.
> random: fast init done
> Starting logging: OK
> usb 1-1: new full-speed USB device number 2 using sm501-usb
> Initializing random number generator... done.
> Starting network...
> ip: OVERRUN: Invalid argument
> ip: OVERRUN: Bad address
> ip: OVERRUN: Bad address
> ip: OVERRUN: Bad address
> ip: OVERRUN: Bad address
> [repeats until the test aborts]
> 
> Bisect points to commit 6e050503a150 ("sh: fix copy_from_user()"). Bisect log is
> attached.

BTW, could you post your .config and information about your userland?  E.g.
is that ip(8) a busybox one, etc.  If it's busybox, this smells like EINVAL
and EFAULT resp. coming from recvmsg() on netlink sockets, with nothing
extraordinary in iovecs, AFAICS...