linux-kernel - Re: kernel BUG at mm/highmem.c:417! invalid opcode: 0000 EIP: zero_user

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]

Message-ID: <20201124171628.dk6tle5lh3sx2jxg@linutronix.de>
Date:   Tue, 24 Nov 2020 18:16:28 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Naresh Kamboju <naresh.kamboju@...aro.org>
Cc:     open list <linux-kernel@...r.kernel.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, lkft-triage@...ts.linaro.org,
        LTP List <ltp@...ts.linux.it>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        torvalds@...uxfoundation.org, Yang Shi <shy828301@...il.com>,
        Jan Kara <jack@...e.cz>, Michal Hocko <mhocko@...e.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Mel Gorman <mgorman@...e.de>, Song Liu <songliubraving@...com>,
        Zi Yan <ziy@...dia.com>, vtolkm@...glemail.com,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: kernel BUG at mm/highmem.c:417! invalid opcode: 0000 EIP:
 zero_user_segments

On 2020-11-24 18:52:44 [+0530], Naresh Kamboju wrote:
> While running LTP test case access01 the following kernel BUG
> noticed on linux next 20201124 tag kernel on i386.
> 
> git short log:
> ----------------
> git log --oneline next-20201120..next-20201124 -- mm/highmem.c
> d9927d46febf Merge branch 'akpm-current/current'
> 72d22a0d0e86 mm: support THPs in zero_user_segments
> 2a656cad337e mm/highmem: Take kmap_high_get() properly into account
> 
> Please find these easy steps to reproduce the kernel build and boot.

This BUG_ON() is in zero_user_segments() which ash been added in commit
   72d22a0d0e86 mm: support THPs in zero_user_segments

> [   50.852189] kernel BUG at mm/highmem.c:417!

I managed to capture one invocation with:
zero_user_segments(0xd4367a90,
		   0x1000, 0x1000,
		   0x0, 0x50)
page_compound() -> 1
page_size() -> 4096

And at the end it BUGs because end2 is still 0x50.

because:
|         for (i = 0; i < compound_nr(page); i++) {
|                 void *kaddr;
|                 unsigned this_end;
| 
|                 if (end1 == 0 && start2 >= PAGE_SIZE) {
|                         start2 -= PAGE_SIZE;
|                         end2 -= PAGE_SIZE;
|                         continue;
|                 }
| 
|                 if (start1 >= PAGE_SIZE) {
start1 0x1000 is >= PAGE_SIZE.
|                         start1 -= PAGE_SIZE;
|                         end1 -= PAGE_SIZE;
|                         if (start2) {
start2 is 0.
|                                 start2 -= PAGE_SIZE;
|                                 end2 -= PAGE_SIZE;
|                         }
|                         continue;
|                 }

I don't know why the logic for start1/end1 and start2/end2 is coupled
here.  Based on how __block_write_begin_int() invokes it seems to zero
two independent blocks (or it is a bug in caller).
The generic implementation would do nothing for start1/end1 and for
second part if would memset(page + 0, 0, 0x50 - 0).

Sebastian