Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1441641 > unrolled thread

[PATCH v7 1/2] mm, kasan: account for object redzone in SLUB's nearest_obj()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v7 1/2] mm, kasan: account for object redzone in SLUB's nearest_obj() Alexander Potapenko <glider@google.com> - 2016-07-12 20:20 +0200
    Re: [PATCH v7 1/2] mm, kasan: account for object redzone in SLUB's  nearest_obj() Andrew Morton <akpm@linux-foundation.org> - 2016-07-12 22:10 +0200
      Re: [PATCH v7 1/2] mm, kasan: account for object redzone in SLUB's nearest_obj() Alexander Potapenko <glider@google.com> - 2016-07-13 14:20 +0200

#1441641 — [PATCH v7 1/2] mm, kasan: account for object redzone in SLUB's nearest_obj()

When looking up the nearest SLUB object for a given address, correctly
calculate its offset if SLAB_RED_ZONE is enabled for that cache.

Fixes: 7ed2f9e663854db ("mm, kasan: SLAB support")
Signed-off-by: Alexander Potapenko <glider@google.com>
---
 include/linux/slub_def.h | 10 ++++++----
 mm/slub.c                |  2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index d1faa01..b71b258 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -114,15 +114,17 @@ static inline void sysfs_slab_remove(struct kmem_cache *s)
 void object_err(struct kmem_cache *s, struct page *page,
 		u8 *object, char *reason);
 
+void *fixup_red_left(struct kmem_cache *s, void *p);
+
 static inline void *nearest_obj(struct kmem_cache *cache, struct page *page,
 				void *x) {
 	void *object = x - (x - page_address(page)) % cache->size;
 	void *last_object = page_address(page) +
 		(page->objects - 1) * cache->size;
-	if (unlikely(object > last_object))
-		return last_object;
-	else
-		return object;
+	void *result = (unlikely(object > last_object)) ? last_object : object;
+
+	result = fixup_red_left(cache, result);
+	return result;
 }
 
 #endif /* _LINUX_SLUB_DEF_H */
diff --git a/mm/slub.c b/mm/slub.c
index 825ff45..27cbef9 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -124,7 +124,7 @@ static inline int kmem_cache_debug(struct kmem_cache *s)
 #endif
 }
 
-static inline void *fixup_red_left(struct kmem_cache *s, void *p)
+inline void *fixup_red_left(struct kmem_cache *s, void *p)
 {
 	if (kmem_cache_debug(s) && s->flags & SLAB_RED_ZONE)
 		p += s->red_left_pad;
-- 
2.8.0.rc3.226.g39d4020

[toc] | [next] | [standalone]

#1441703 — Re: [PATCH v7 1/2] mm, kasan: account for object redzone in SLUB's nearest_obj()

On Tue, 12 Jul 2016 20:12:44 +0200 Alexander Potapenko <glider@google.com> wrote:

> When looking up the nearest SLUB object for a given address, correctly
> calculate its offset if SLAB_RED_ZONE is enabled for that cache.

What are the runtime effects of this fix?  Please always include this
info when fixing bugs so that others can decide which kernel(s) need
patching.

[toc] | [prev] | [next] | [standalone]

#1442384

Changed the description as follows:

=================================
    mm, kasan: account for object redzone in SLUB's nearest_obj()

    When looking up the nearest SLUB object for a given address, correctly
    calculate its offset if SLAB_RED_ZONE is enabled for that cache.

    Previously, when KASAN had detected an error on an object from a cache
    with SLAB_RED_ZONE set, the actual start address of the object was
    miscalculated, which led to random stacks having been reported.

    Fixes: 7ed2f9e663854db ("mm, kasan: SLAB support")
    Signed-off-by: Alexander Potapenko <glider@google.com>
=================================

To avoid sending both patches and the cover page again, I'm going to
wait for other comments.

On Tue, Jul 12, 2016 at 10:02 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 12 Jul 2016 20:12:44 +0200 Alexander Potapenko <glider@google.com> wrote:
>
>> When looking up the nearest SLUB object for a given address, correctly
>> calculate its offset if SLAB_RED_ZONE is enabled for that cache.
>
> What are the runtime effects of this fix?  Please always include this
> info when fixing bugs so that others can decide which kernel(s) need
> patching.
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web