linux-kernel - Re: [BUG] arm64: an infinite loop in generic_perform

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:   Wed, 23 Jun 2021 14:22:23 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Chen Huang <chenhuang5@...wei.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Randy Dunlap <rdunlap@...radead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-mm <linux-mm@...ck.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] arm64: an infinite loop in generic_perform_write()

On Wed, Jun 23, 2021 at 10:39:31AM +0800, Chen Huang wrote:
> When we access a device memory in userspace, then perform an unaligned write to a file.
> For example, we register a uio device and mmap the device, then perform an write to a
> file, like that:
> 
> 	device_addr = mmap(device_fd);
> 	write(file_fd, device_addr + unaligned_num, size);

What exactly is this device, and why do you want the kernel to do a
direct memcpy from MMIO? Why can't you copy that in userspace (where you
have knowledge of the device), then pass the copy to a syscall?

Ignoring the lockup below, this isn't going to work in general, since
uaccess routines do not guarantee alignment, single-copy, access sizes,
monotonically increasing addresses, etc. Any one of those can cause a
device to raise an external abort which may or may not be synchronous.

It does not make sense to tell the kernel to access this, since the
kernel cannot know how to access it safely, and we can;t do that without
knowledge of the device that we do not have.

Thanks,
Mark.

> 	
> We found that the infinite loop happened in generic_perform_write function:
> 
> again:
> 	copied = copy_page_from_iter_atomic(); //copied = 0
> 	status = ops->write_end(); //status = 0
> 	if (status == 0)
> 		goto again;
> 
> In copy_page_from_iter_atomic, the copyin() function finally call
> __arch_copy_from_user which create an exception table entry for 'insn'.
> Then when kernel handles the alignment_fault, it will not panic. As the
> arm64 memory model spec said, when the address is not a multiple of the
> element size, the access is unaligned. Unaligned accesses are allowed to
> addresses marked as Normal, but not to Device regions. An unaligned access
> to a Device region will trigger an exception (alignment fault).
> 	
> do_alignment_fault
>     do_bad_area
> 	__do_kernel_fault
>            fixup_exception
> 
> But that fixup cann't handle the unaligned copy, so the
> copy_page_from_iter_atomic returns 0 and traps in loop.
> 
> Reported-by: Chen Huang <chenhuang5@...wei.com>