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-next>] [day] [month] [year] [list]
Message-ID: <CAJC5FUVt-QxOGv-sgrfAQtGmw=J1+vXQfsMtrRHfXt-j0YtFqg@mail.gmail.com>
Date:	Tue, 11 Aug 2015 16:39:08 +0530
From:	Ankit Jindal <ajindal@....com>
To:	linux-kernel@...r.kernel.org
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Hans J. Koch" <hjk@...sjkoch.de>,
	Pranavkumar Sawargaonkar <psawargaonkar@....com>,
	Jitendra Kanitkar <jkanitkar@....com>,
	Tushar Jagad <tjagad@....com>
Subject: Unmapping of UIO logical memory causing a trace

Hi,

We have observed an issue where kmalloc of a small sized memory causes
an occasional trace when unmapping the mmaped memory via UIO framework
This trace is coming when kernel sees a negative value in
page->_mapcount. Trace is pasted at the end of the mail.

After debugging this issue further, we realized following sequence
occurs when kmalloc is used to allocate small memory using slub
allocator:
1. Frozen bit (msb) of the page from which memory has been allocated
is set (which is an union with _mapcount).
2. If there are free objects in the the same page then this frozen bit
remains set even after kernel boots completely.
3. When user space calls unmap of this memory, vma_unmap_single()
treats the _mapcount as a negative (as frozen bit is set), causing a
trace.

We are not sure whether exposing kernel memory of size
less than PAGE_SIZE via UIO is a valid use case ? In case this is an invalid
use case then shouldn't the UIO framework restrict mapping of non
PAGE_SIZE aligned memory and size not in order of PAGE_SIZE.

Trace:

BUG: Bad page map in process test-mumap  pte:2a00040ef92af53 pmd:43ad50a003
page:ffffffbec3be4a80 count:2 mapcount:0x82000201 mapping:
(null) index:0x0
flags: 0x94(referenced|dirty|slab)
page dumped because: bad pte
addr:0000007fad20a000 vm_flags:040400ff anon_vma:          (null)
mapping:ffffffc3ad9c6630 index:3
file:uio0 fault:uio_vma_fault mmap:uio_mmap readpage:          (null)
CPU: 0 PID: 2179 Comm: test-xgene-qmtm Not tainted 4.1.0 #102
Hardware name: APM board (DT)
Call trace:
[<ffffffc000088b40>] dump_backtrace+0x0/0x124
[<ffffffc000088c74>] show_stack+0x10/0x1c
[<ffffffc000908328>] dump_stack+0x84/0xc8
[<ffffffc000150404>] print_bad_pte+0x15c/0x1f8
[<ffffffc000151e90>] unmap_single_vma+0x478/0x678
[<ffffffc000152934>] unmap_vmas+0x64/0xd4
[<ffffffc000157a7c>] unmap_region+0x8c/0x140
[<ffffffc000159b1c>] do_munmap+0x174/0x3c4
[<ffffffc000159dac>] vm_munmap+0x40/0x64
[<ffffffc00015ac20>] SyS_munmap+0x20/0x34

Thanks,
Ankit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ