linux-kernel - Re: [PATCH v2] dax: fix NULL pointer in __dax_pmd

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:	Tue, 22 Sep 2015 14:13:33 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ross Zwisler <ross.zwisler@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Matthew Wilcox <willy@...ux.intel.com>,
	linux-fsdevel@...r.kernel.org,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	linux-nvdimm@...1.01.org, Dan Williams <dan.j.williams@...el.com>,
	Dave Chinner <david@...morbit.com>
Subject: Re: [PATCH v2] dax: fix NULL pointer in __dax_pmd_fault()

On Tue, 22 Sep 2015 13:36:22 -0600 Ross Zwisler <ross.zwisler@...ux.intel.com> wrote:

> The following commit:
> 
> commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for
> 	DAX")
> 
> moved some code in __dax_pmd_fault() that was responsible for zeroing
> newly allocated PMD pages.  The new location didn't properly set up
> 'kaddr', though, so when run this code resulted in a NULL pointer BUG.
> 
> Fix this by getting the correct 'kaddr' via bdev_direct_access().

Why the heck didn't gcc warn?

I had a fiddle:

--- a/fs/dax.c~a
+++ a/fs/dax.c
@@ -529,15 +529,18 @@ int __dax_pmd_fault(struct vm_area_struc
 	unsigned long pmd_addr = address & PMD_MASK;
 	bool write = flags & FAULT_FLAG_WRITE;
 	long length;
-	void __pmem *kaddr;
+	void *kaddr;
 	pgoff_t size, pgoff;
 	sector_t block, sector;
 	unsigned long pfn;
 	int result = 0;
 
+//	printk("%p\n", kaddr);
+
 	/* Fall back to PTEs if we're going to COW */
 	if (write && !(vma->vm_flags & VM_SHARED))
 		return VM_FAULT_FALLBACK;
+	printk("%p\n", kaddr);
 	/* If the PMD would extend outside the VMA */
 	if (pmd_addr < vma->vm_start)
 		return VM_FAULT_FALLBACK;

gcc warns about the first printk, but not about the second.  So that
"if (...) return ..." seems to have defeated gcc uninitialized-var
detection.  wtf?

> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -569,8 +569,20 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned long address,
>  	if (!buffer_size_valid(&bh) || bh.b_size < PMD_SIZE)
>  		goto fallback;
>  
> +	sector = bh.b_blocknr << (blkbits - 9);
> +
>  	if (buffer_unwritten(&bh) || buffer_new(&bh)) {
>  		int i;
> +
> +		length = bdev_direct_access(bh.b_bdev, sector, &kaddr, &pfn,
> +						bh.b_size);
> +		if (length < 0) {
> +			result = VM_FAULT_SIGBUS;
> +			goto out;
> +		}
> +		if ((length < PMD_SIZE) || (pfn & PG_PMD_COLOUR))
> +			goto fallback;
> +
>  		for (i = 0; i < PTRS_PER_PMD; i++)
>  			clear_pmem(kaddr + i * PAGE_SIZE, PAGE_SIZE);
>  		wmb_pmem();

hm, that's a lot of copy-n-paste.  Do we really need to run
bdev_direct_access() twice?  Will `kaddr' and `pfn' change?

--
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/