On Fri, Jul 14, 2017 at 7:25 AM, Dave Jones <davej@xxxxxxxxxxxxxxxxx> wrote:
> On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote:
> >
> > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1
>
> Since this landed, I'm seeing this during boot..
>
> ==================================================================
> BUG: KASAN: global-out-of-bounds in strscpy+0x4a/0x230
> Read of size 8 at addr ffffffffb4eeaf20 by task nfsd/688
Is KASAN aware that strscpy() does the word-at-a-time optimistic reads
of the sources?
The problem may be that the source is initialized from the global
string "nfsd", and KASAN may be unhappy abotu the fact that we read 8
bytes from a 5-byte string (four plus NUL) as we do the word-at-a-time
strscpy..
That said, we do check the size first (because we also *write* 8 bytes
at a time), so maybe KASAN shouldn't even need to care.
Hmm. it really looks to me like this is actually a compiler bug (I'm
using current gcc in F26, which is gcc-7.1.1 - I'm assuming DaveJ is
the same).
This is the source code in __ip_map_lookup:
struct ip_map ip;
.....
strcpy(ip.m_class, class);
and "m_class" is 8 bytes in size:
struct ip_map {
...
char m_class[8]; /* e.g. "nfsd" */
...
yet when I look at the generated code for __ip_map_lookup, I see
movl $32, %edx #,
movq %r13, %rsi # class,
leaq 48(%rax), %rdi #, tmp126
call strscpy #
what's the bug here? Look at that third argument - %rdx. It is
initialized to 32.
WTF?
The code to turn "strcpy()" into "strscpy()" should pick the *smaller*
of the two object sizes as the size argument. How the hell is that
size argument 32?
Am I missing something? DaveJ, do you see the same?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
