linux-kernel - introduce probe_slab_address? (Was: sched/numa: fix unsafe get_task_struct() in task_numa

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: <20141022181412.GA8159@redhat.com>
Date:	Wed, 22 Oct 2014 20:14:12 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>,
	Christoph Lameter <cl@...ux.com>,
	David Miller <davem@...emloft.net>
Cc:	Kirill Tkhai <tkhai@...dex.ru>,
	Kirill Tkhai <ktkhai@...allels.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Vladimir Davydov <vdavydov@...allels.com>, cl@...ux.com
Subject: introduce probe_slab_address? (Was: sched/numa: fix unsafe
	get_task_struct() in task_numa_assign())

Add cc's.

On 10/22, Peter Zijlstra wrote:
>
> On Wed, Oct 22, 2014 at 06:14:50PM +0200, Oleg Nesterov wrote:
> > Hmm. so perhaps I misunderstood your concern...
> >
> > Do you mean that on !x86 a plain LOAD can "corrupt" the memory as it seen
> > from another vaddr?
>
> I'm not sure. Stores for sure, loads I'm not sure about.
>
> I suspect loads are OK, the aliasing cacheline will be !modified and
> therefore later eviction should discard (not write back). But like said,
> I'm not at all sure.
>
> I would hesitate to put such assumptions into generic code -- although
> it appears we already have.

So perhaps something like this makes sense?

If some arch has problems with D-cache aliasing (because the freed page
can be already mapped by user-space or vmalloc'ed), it can redefine this
helper.

Do you think we can use it to access rq->curr? (although let me repeat
that I won't really argue with SLAB_DESTROY_BY_RCU).

Oleg.


diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index ecd3319..eb8494c 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -84,6 +84,22 @@ static inline unsigned long __copy_from_user_nocache(void *to,
 	})
 
 /*
+ * @addr is the valid kernel pointer but this memory can be freed.
+ */
+#ifndef probe_slab_address
+#ifdef CONFIG_DEBUG_PAGEALLOC
+#define probe_slab_address(addr, retval)	\
+	probe_kernel_address(addr, retval)
+#else
+#define probe_slab_address(addr, retval)	\
+	({							\
+		(retval) = *(typeof(retval) *)(addr);		\
+		0;						\
+	})
+#endif
+#endif
+
+/*
  * probe_kernel_read(): safely attempt to read from a location
  * @dst: pointer to the buffer that shall take the data
  * @src: address to read from
diff --git a/mm/slub.c b/mm/slub.c
index 3e8afcc..0467d22 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -265,11 +265,7 @@ static inline void *get_freepointer_safe(struct kmem_cache *s, void *object)
 {
 	void *p;
 
-#ifdef CONFIG_DEBUG_PAGEALLOC
-	probe_kernel_read(&p, (void **)(object + s->offset), sizeof(p));
-#else
-	p = get_freepointer(s, object);
-#endif
+	probe_slab_address(object + s->offset, p);
 	return p;
 }
 

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