With the introduction of commit e39a97353e53 ("scsi: core: return
BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command that
failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but lacking
additional sense information will have a return code set to BLK_STS_OK.
This results in the request issuer to see successful request execution
despite the failure. An example of such case is an unaligned write on a
host managed ZAC disk connected to a SAS HBA with a malfunctioning SAT.
The unaligned write command gets aborted but has no additional sense
information.
sd 10:0:0:0: [sde] tag#3905 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 10:0:0:0: [sde] tag#3905 Sense Key : Aborted Command [current]
sd 10:0:0:0: [sde] tag#3905 Add. Sense: No additional sense information
sd 10:0:0:0: [sde] tag#3905 CDB: Write(16) 8a 00 00 00 00 00 02 0c 00 01 00 00 00 01 00 00
print_req_error: I/O error, dev sde, sector 274726920
In scsi_io_completion(), sense key handling to not change the request
error code and success being reported to the issuer.
Fix this by making sure that the error code always indicates an error
if scsi_io_completion() decide that the action to be taken for a failed
command is to not retry it and terminate it immediately (ACTION_FAIL) .
Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com>
Signed-off-by: Hannes Reinecke <hare(a)suse.com>
Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()")
Cc: <stable(a)vger.kernel.org>
---
drivers/scsi/scsi_lib.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 393f9db8f41b..9389c41e2829 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -905,6 +905,12 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
goto requeue;
error = __scsi_error_from_host_byte(cmd, result);
+ /*
+ * If the hostbyte was DID_OK, but the sense code is valid
+ * we always should set BLK_STS_IOERR.
+ */
+ if (error == BLK_STS_OK && sense_valid)
+ error = BLK_STS_IOERR;
if (host_byte(result) == DID_RESET) {
/* Third party bus reset or reset for error recovery
--
2.12.3
Hi Greg,
Those are the backports meant to solve CVE-2017-13166 on Kernel 3.18.
It contains two v4l2-ctrls fixes that are required to avoid crashes
at the test application.
I wrote two patches myself for Kernel 3.18 in order to solve some
issues specific for Kernel 3.18 with aren't needed upstream.
one is actually a one-line change backport. The other one makes
sure that both 32-bits and 64-bits version of some ioctl calls
will return the same value for a reserved field.
I noticed an extra bug while testing it, but the bug also hits upstream,
and should be backported all the way down all stable/LTS versions.
So, I'll send it the usual way, after merging upsream.
Regards,
Mauro
Daniel Mentz (2):
media: v4l2-compat-ioctl32: Copy v4l2_window->global_alpha
media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic
Hans Verkuil (12):
media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
media: v4l2-compat-ioctl32.c: fix the indentation
media: v4l2-compat-ioctl32.c: move 'helper' functions to
__get/put_v4l2_format32
media: v4l2-compat-ioctl32.c: avoid sizeof(type)
media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32
media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer
media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32
media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type
media: v4l2-compat-ioctl32.c: don't copy back the result for certain
errors
media: v4l2-ctrls: fix sparse warning
Mauro Carvalho Chehab (2):
media: v4l2-compat-ioctl32: use compat_u64 for video standard
media: v4l2-compat-ioctl32: initialize a reserved field
Ricardo Ribalda (2):
vb2: V4L2_BUF_FLAG_DONE is set after DQBUF
media: media/v4l2-ctrls: volatiles should not generate CH_VALUE
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1020 +++++++++++++++----------
drivers/media/v4l2-core/v4l2-ctrls.c | 96 ++-
drivers/media/v4l2-core/v4l2-ioctl.c | 5 +-
drivers/media/v4l2-core/videobuf2-core.c | 5 +
4 files changed, 691 insertions(+), 435 deletions(-)
--
2.14.3
This is a note to let you know that I've just added the patch titled
media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3ee6d040719ae09110e5cdf24d5386abe5d1b776 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Wed, 24 Jan 2018 08:37:04 -0500
Subject: media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
From: Hans Verkuil <hans.verkuil(a)cisco.com>
commit 3ee6d040719ae09110e5cdf24d5386abe5d1b776 upstream.
The result of the VIDIOC_PREPARE_BUF ioctl was never copied back
to userspace since it was missing in the switch.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # for v4.15 and up
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -996,6 +996,7 @@ static long do_video_ioctl(struct file *
err = put_v4l2_create32(&karg.v2crt, up);
break;
+ case VIDIOC_PREPARE_BUF:
case VIDIOC_QUERYBUF:
case VIDIOC_QBUF:
case VIDIOC_DQBUF:
Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are
queue-3.18/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-3.18/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-3.18/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-3.18/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-3.18/vb2-v4l2_buf_flag_done-is-set-after-dqbuf.patch
queue-3.18/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-3.18/media-v4l2-ctrls-fix-sparse-warning.patch
queue-3.18/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-3.18/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-3.18/media-media-v4l2-ctrls-volatiles-should-not-generate-ch_value.patch
queue-3.18/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-3.18/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-3.18/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-3.18/media-v4l2-compat-ioctl32-copy-v4l2_window-global_alpha.patch
queue-3.18/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-3.18/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: vsp1: Fix BRx conditional path in WPF
Author: Kieran Bingham <kieran.bingham(a)ideasonboard.com>
Date: Mon Mar 26 09:29:17 2018 -0400
When a BRx is provided by a pipeline, the WPF must determine the master
layer. Currently the condition to check this identifies pipe->bru ||
pipe->num_inputs > 1.
The code then moves on to dereference pipe->bru, thus the check fails
static analysers on the possibility that pipe->num_inputs could be
greater than 1 without pipe->bru being set.
The reality is that the pipeline must have a BRx to support more than
one input, thus this could never cause a fault - however it also
identifies that the num_inputs > 1 check is redundant.
Remove the redundant check - and always configure the master layer
appropriately when we have a BRx configured in our pipeline.
Fixes: 6134148f6098 ("v4l: vsp1: Add support for the BRS entity")
Cc: stable(a)vger.kernel.org
Suggested-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/platform/vsp1/vsp1_wpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c b/drivers/media/platform/vsp1/vsp1_wpf.c
index f7f3b4b2c2de..8bd6b2f1af15 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -452,7 +452,7 @@ static void wpf_configure(struct vsp1_entity *entity,
: VI6_WPF_SRCRPF_RPF_ACT_SUB(input->entity.index);
}
- if (pipe->bru || pipe->num_inputs > 1)
+ if (pipe->bru)
srcrpf |= pipe->bru->type == VSP1_ENTITY_BRU
? VI6_WPF_SRCRPF_VIRACT_MST
: VI6_WPF_SRCRPF_VIRACT2_MST;
From: Xidong Wang <wangxidong_97(a)163.com>
Along the eb_lookup_vmas() error path, the return value from
kmem_cache_alloc() was freed using kfree(). Fix it to use the proper
kmem_cache_free() instead.
Fixes: d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: Xidong Wang <wangxidong_97(a)163.com>
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
Cc: <stable(a)vger.kernel.org> # v4.14+
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8c170db8495d..0414228cd2b5 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -728,7 +728,7 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
err = radix_tree_insert(handles_vma, handle, vma);
if (unlikely(err)) {
- kfree(lut);
+ kmem_cache_free(eb->i915->luts, lut);
goto err_obj;
}
--
2.16.3
This is a note to let you know that I've just added the patch titled
bitmap: fix memset optimization on big-endian systems
to the 4.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bitmap-fix-memset-optimization-on-big-endian-systems.patch
and it can be found in the queue-4.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 21035965f60b0502fc6537b232839389bb4ce664 Mon Sep 17 00:00:00 2001
From: Omar Sandoval <osandov(a)fb.com>
Date: Mon, 2 Apr 2018 15:58:31 -0700
Subject: bitmap: fix memset optimization on big-endian systems
From: Omar Sandoval <osandov(a)fb.com>
commit 21035965f60b0502fc6537b232839389bb4ce664 upstream.
Commit 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and
bitmap_clear into memset when possible") introduced an optimization to
bitmap_{set,clear}() which uses memset() when the start and length are
constants aligned to a byte.
This is wrong on big-endian systems; our bitmaps are arrays of unsigned
long, so bit n is not at byte n / 8 in memory. This was caught by the
Btrfs selftests, but the bitmap selftests also fail when run on a
big-endian machine.
We can still use memset if the start and length are aligned to an
unsigned long, so do that on big-endian. The same problem applies to
the memcmp in bitmap_equal(), so fix it there, too.
Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible")
Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations")
Cc: stable(a)kernel.org
Reported-by: "Erhard F." <erhard_f(a)mailbox.org>
Cc: Matthew Wilcox <mawilcox(a)microsoft.com>
Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Omar Sandoval <osandov(a)fb.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/bitmap.h | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -302,12 +302,20 @@ static inline void bitmap_complement(uns
__bitmap_complement(dst, src, nbits);
}
+#ifdef __LITTLE_ENDIAN
+#define BITMAP_MEM_ALIGNMENT 8
+#else
+#define BITMAP_MEM_ALIGNMENT (8 * sizeof(unsigned long))
+#endif
+#define BITMAP_MEM_MASK (BITMAP_MEM_ALIGNMENT - 1)
+
static inline int bitmap_equal(const unsigned long *src1,
const unsigned long *src2, unsigned int nbits)
{
if (small_const_nbits(nbits))
return !((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits));
- if (__builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
+ if (__builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
return !memcmp(src1, src2, nbits / 8);
return __bitmap_equal(src1, src2, nbits);
}
@@ -358,8 +366,10 @@ static __always_inline void bitmap_set(u
{
if (__builtin_constant_p(nbits) && nbits == 1)
__set_bit(start, map);
- else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) &&
- __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
+ else if (__builtin_constant_p(start & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) &&
+ __builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
memset((char *)map + start / 8, 0xff, nbits / 8);
else
__bitmap_set(map, start, nbits);
@@ -370,8 +380,10 @@ static __always_inline void bitmap_clear
{
if (__builtin_constant_p(nbits) && nbits == 1)
__clear_bit(start, map);
- else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) &&
- __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
+ else if (__builtin_constant_p(start & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) &&
+ __builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
memset((char *)map + start / 8, 0, nbits / 8);
else
__bitmap_clear(map, start, nbits);
Patches currently in stable-queue which might be from osandov(a)fb.com are
queue-4.16/bitmap-fix-memset-optimization-on-big-endian-systems.patch
This is a note to let you know that I've just added the patch titled
bitmap: fix memset optimization on big-endian systems
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bitmap-fix-memset-optimization-on-big-endian-systems.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 21035965f60b0502fc6537b232839389bb4ce664 Mon Sep 17 00:00:00 2001
From: Omar Sandoval <osandov(a)fb.com>
Date: Mon, 2 Apr 2018 15:58:31 -0700
Subject: bitmap: fix memset optimization on big-endian systems
From: Omar Sandoval <osandov(a)fb.com>
commit 21035965f60b0502fc6537b232839389bb4ce664 upstream.
Commit 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and
bitmap_clear into memset when possible") introduced an optimization to
bitmap_{set,clear}() which uses memset() when the start and length are
constants aligned to a byte.
This is wrong on big-endian systems; our bitmaps are arrays of unsigned
long, so bit n is not at byte n / 8 in memory. This was caught by the
Btrfs selftests, but the bitmap selftests also fail when run on a
big-endian machine.
We can still use memset if the start and length are aligned to an
unsigned long, so do that on big-endian. The same problem applies to
the memcmp in bitmap_equal(), so fix it there, too.
Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible")
Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations")
Cc: stable(a)kernel.org
Reported-by: "Erhard F." <erhard_f(a)mailbox.org>
Cc: Matthew Wilcox <mawilcox(a)microsoft.com>
Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Omar Sandoval <osandov(a)fb.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/bitmap.h | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -271,12 +271,20 @@ static inline void bitmap_complement(uns
__bitmap_complement(dst, src, nbits);
}
+#ifdef __LITTLE_ENDIAN
+#define BITMAP_MEM_ALIGNMENT 8
+#else
+#define BITMAP_MEM_ALIGNMENT (8 * sizeof(unsigned long))
+#endif
+#define BITMAP_MEM_MASK (BITMAP_MEM_ALIGNMENT - 1)
+
static inline int bitmap_equal(const unsigned long *src1,
const unsigned long *src2, unsigned int nbits)
{
if (small_const_nbits(nbits))
return !((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits));
- if (__builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
+ if (__builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
return !memcmp(src1, src2, nbits / 8);
return __bitmap_equal(src1, src2, nbits);
}
@@ -327,8 +335,10 @@ static __always_inline void bitmap_set(u
{
if (__builtin_constant_p(nbits) && nbits == 1)
__set_bit(start, map);
- else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) &&
- __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
+ else if (__builtin_constant_p(start & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) &&
+ __builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
memset((char *)map + start / 8, 0xff, nbits / 8);
else
__bitmap_set(map, start, nbits);
@@ -339,8 +349,10 @@ static __always_inline void bitmap_clear
{
if (__builtin_constant_p(nbits) && nbits == 1)
__clear_bit(start, map);
- else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) &&
- __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
+ else if (__builtin_constant_p(start & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) &&
+ __builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
memset((char *)map + start / 8, 0, nbits / 8);
else
__bitmap_clear(map, start, nbits);
Patches currently in stable-queue which might be from osandov(a)fb.com are
queue-4.15/bitmap-fix-memset-optimization-on-big-endian-systems.patch
This is a note to let you know that I've just added the patch titled
bitmap: fix memset optimization on big-endian systems
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bitmap-fix-memset-optimization-on-big-endian-systems.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 21035965f60b0502fc6537b232839389bb4ce664 Mon Sep 17 00:00:00 2001
From: Omar Sandoval <osandov(a)fb.com>
Date: Mon, 2 Apr 2018 15:58:31 -0700
Subject: bitmap: fix memset optimization on big-endian systems
From: Omar Sandoval <osandov(a)fb.com>
commit 21035965f60b0502fc6537b232839389bb4ce664 upstream.
Commit 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and
bitmap_clear into memset when possible") introduced an optimization to
bitmap_{set,clear}() which uses memset() when the start and length are
constants aligned to a byte.
This is wrong on big-endian systems; our bitmaps are arrays of unsigned
long, so bit n is not at byte n / 8 in memory. This was caught by the
Btrfs selftests, but the bitmap selftests also fail when run on a
big-endian machine.
We can still use memset if the start and length are aligned to an
unsigned long, so do that on big-endian. The same problem applies to
the memcmp in bitmap_equal(), so fix it there, too.
Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible")
Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations")
Cc: stable(a)kernel.org
Reported-by: "Erhard F." <erhard_f(a)mailbox.org>
Cc: Matthew Wilcox <mawilcox(a)microsoft.com>
Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Omar Sandoval <osandov(a)fb.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/bitmap.h | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -262,12 +262,20 @@ static inline void bitmap_complement(uns
__bitmap_complement(dst, src, nbits);
}
+#ifdef __LITTLE_ENDIAN
+#define BITMAP_MEM_ALIGNMENT 8
+#else
+#define BITMAP_MEM_ALIGNMENT (8 * sizeof(unsigned long))
+#endif
+#define BITMAP_MEM_MASK (BITMAP_MEM_ALIGNMENT - 1)
+
static inline int bitmap_equal(const unsigned long *src1,
const unsigned long *src2, unsigned int nbits)
{
if (small_const_nbits(nbits))
return !((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits));
- if (__builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
+ if (__builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
return !memcmp(src1, src2, nbits / 8);
return __bitmap_equal(src1, src2, nbits);
}
@@ -318,8 +326,10 @@ static __always_inline void bitmap_set(u
{
if (__builtin_constant_p(nbits) && nbits == 1)
__set_bit(start, map);
- else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) &&
- __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
+ else if (__builtin_constant_p(start & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) &&
+ __builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
memset((char *)map + start / 8, 0xff, nbits / 8);
else
__bitmap_set(map, start, nbits);
@@ -330,8 +340,10 @@ static __always_inline void bitmap_clear
{
if (__builtin_constant_p(nbits) && nbits == 1)
__clear_bit(start, map);
- else if (__builtin_constant_p(start & 7) && IS_ALIGNED(start, 8) &&
- __builtin_constant_p(nbits & 7) && IS_ALIGNED(nbits, 8))
+ else if (__builtin_constant_p(start & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) &&
+ __builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+ IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
memset((char *)map + start / 8, 0, nbits / 8);
else
__bitmap_clear(map, start, nbits);
Patches currently in stable-queue which might be from osandov(a)fb.com are
queue-4.14/bitmap-fix-memset-optimization-on-big-endian-systems.patch
With the introduction of commit e39a97353e53 ("scsi: core: return
BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command that
failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but lacking
additional sense information will have a return code set to BLK_STS_OK.
This results in the request issuer to see successful request execution
despite the failure. An example of such case is an unaligned write on a
host managed ZAC disk connected to a SAS HBA with a malfunctioning SAT.
The unaligned write command gets aborted but has no additional sense
information.
sd 10:0:0:0: [sde] tag#3905 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 10:0:0:0: [sde] tag#3905 Sense Key : Aborted Command [current]
sd 10:0:0:0: [sde] tag#3905 Add. Sense: No additional sense information
sd 10:0:0:0: [sde] tag#3905 CDB: Write(16) 8a 00 00 00 00 00 02 0c 00 01 00 00 00 01 00 00
print_req_error: I/O error, dev sde, sector 274726920
In scsi_io_completion(), sense key handling to not change the request
error code and success being reported to the issuer.
Fix this by making sure that the error code always indicates an error
if scsi_io_completion() decide that the action to be taken for a failed
command is to not retry it and terminate it immediately (ACTION_FAIL) .
Signed-off-by: Damien Le Moal <damien.lemoal(a)wdc.com>
Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()")
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: <stable(a)vger.kernel.org>
---
drivers/scsi/scsi_lib.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index c84f931388f2..87579bfcc186 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1002,6 +1002,15 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
scsi_print_command(cmd);
}
}
+ /*
+ * The command failed and should not be retried. If the host
+ * byte is DID_OK, then __scsi_error_from_host_byte() returned
+ * BLK_STS_OK and error indicates a success. Make sure to not
+ * use that as the completion code and always return an
+ * I/O error.
+ */
+ if (error == BLK_STS_OK)
+ error = BLK_STS_IOERR;
if (!scsi_end_request(req, error, blk_rq_err_bytes(req), 0))
return;
/*FALLTHRU*/
--
2.14.3
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
The commit "memcontrol: Prevent scheduling while atomic in cgroup code"
fixed this issue:
refill_stock()
get_cpu_var()
drain_stock()
res_counter_uncharge()
res_counter_uncharge_until()
spin_lock() <== boom
But commit 3e32cb2e0a12b ("mm: memcontrol: lockless page counters") replaced
the calls to res_counter_uncharge() in drain_stock() to the lockless
function page_counter_uncharge(). There is no more spin lock there and no
more reason to have that local lock.
Cc: <stable(a)vger.kernel.org>
Reported-by: Haiyang HY1 Tan <tanhy1(a)lenovo.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
[bigeasy: That upstream commit appeared in v3.19 and the patch in
question in v3.18.7-rt2 and v3.18 seems still to be maintained. So I
guess that v3.18 would need the locallocks that we are about to remove
here. I am not sure if any earlier versions have the patch
backported.
The stable tag here is because Haiyang reported (and debugged) a crash
in 4.4-RT with this patch applied (which has get_cpu_light() instead
the locallocks it gained in v4.9-RT).
https://lkml.kernel.org/r/05AA4EC5C6EC1D48BE2CDCFF3AE0B8A637F78A15@CNMAILEX…
]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
---
mm/memcontrol.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 493b4986d5dc..56f67a15937b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1925,17 +1925,14 @@ static void drain_local_stock(struct work_struct *dummy)
*/
static void refill_stock(struct mem_cgroup *memcg, unsigned int nr_pages)
{
- struct memcg_stock_pcp *stock;
- int cpu = get_cpu_light();
-
- stock = &per_cpu(memcg_stock, cpu);
+ struct memcg_stock_pcp *stock = &get_cpu_var(memcg_stock);
if (stock->cached != memcg) { /* reset if necessary */
drain_stock(stock);
stock->cached = memcg;
}
stock->nr_pages += nr_pages;
- put_cpu_light();
+ put_cpu_var(memcg_stock);
}
/*
--
2.14.3
From: Thomas Gleixner <tglx(a)linutronix.de>
The timer start debug function is called before the proper timer base is
set. As a consequence the trace data contains the stale CPU and flags
values.
Call the debug function after setting the new base and flags.
Fixes: 500462a9de65 ("timers: Switch to a non-cascading wheel")
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: stable(a)vger.kernel.org
Cc: rt(a)linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
---
kernel/time/timer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index a8246d79cb5a..6b322aea1c46 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -838,8 +838,6 @@ __mod_timer(struct timer_list *timer, unsigned long expires,
if (!ret && pending_only)
goto out_unlock;
- debug_activate(timer, expires);
-
new_base = get_target_base(base, pinned);
if (base != new_base) {
@@ -854,6 +852,8 @@ __mod_timer(struct timer_list *timer, unsigned long expires,
base = switch_timer_base(timer, base, new_base);
}
+ debug_activate(timer, expires);
+
timer->expires = expires;
internal_add_timer(base, timer);
--
2.14.3
[BUG]
fstrim on some btrfs only trims the unallocated space, not trimming any
space in existing block groups.
[CAUSE]
Before fstrim_range passed to btrfs_trim_fs(), it get truncated to
range [0, super->total_bytes).
So later btrfs_trim_fs() will only be able to trim block groups in range
[0, super->total_bytes).
While for btrfs, any bytenr aligned to sector size is valid, since btrfs use
its logical address space, there is nothing limiting the location where
we put block groups.
For btrfs with routine balance, it's quite easy to relocate all
block groups and bytenr of block groups will start beyond super->total_bytes.
In that case, btrfs will not trim existing block groups.
[FIX]
Just remove the truncation in btrfs_ioctl_fitrim(), so btrfs_trim_fs()
can get the unmodified range, which is normally set to [0, U64_MAX].
Reported-by: Chris Murphy <lists(a)colorremedies.com>
Fixes: f4c697e6406d ("btrfs: return EINVAL if start > total_bytes in fitrim ioctl")
Cc: <stable(a)vger.kernel.org> # v4.0+
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
---
fs/btrfs/extent-tree.c | 10 +---------
fs/btrfs/ioctl.c | 11 +++++++----
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index f3b088665b7a..647691fc16e8 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -10994,19 +10994,11 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
u64 start;
u64 end;
u64 trimmed = 0;
- u64 total_bytes = btrfs_super_total_bytes(fs_info->super_copy);
int bg_ret = 0;
int dev_ret = 0;
int ret = 0;
- /*
- * try to trim all FS space, our block group may start from non-zero.
- */
- if (range->len == total_bytes)
- cache = btrfs_lookup_first_block_group(fs_info, range->start);
- else
- cache = btrfs_lookup_block_group(fs_info, range->start);
-
+ cache = btrfs_lookup_first_block_group(fs_info, range->start);
for (; cache; cache = next_block_group(fs_info, cache)) {
if (cache->key.objectid >= (range->start + range->len)) {
btrfs_put_block_group(cache);
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index ac85e07f567b..761fba8d8f75 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -364,7 +364,6 @@ static noinline int btrfs_ioctl_fitrim(struct file *file, void __user *arg)
struct fstrim_range range;
u64 minlen = ULLONG_MAX;
u64 num_devices = 0;
- u64 total_bytes = btrfs_super_total_bytes(fs_info->super_copy);
int ret;
if (!capable(CAP_SYS_ADMIN))
@@ -388,11 +387,15 @@ static noinline int btrfs_ioctl_fitrim(struct file *file, void __user *arg)
return -EOPNOTSUPP;
if (copy_from_user(&range, arg, sizeof(range)))
return -EFAULT;
- if (range.start > total_bytes ||
- range.len < fs_info->sb->s_blocksize)
+
+ /*
+ * NOTE: Don't truncate the range using super->total_bytes.
+ * Bytenr of btrfs block group is in btrfs logical address space,
+ * which can be any sector size aligned bytenr in [0, U64_MAX].
+ */
+ if (range.len < fs_info->sb->s_blocksize)
return -EINVAL;
- range.len = min(range.len, total_bytes - range.start);
range.minlen = max(range.minlen, minlen);
ret = btrfs_trim_fs(fs_info, &range);
if (ret < 0)
--
2.16.3
Commit aa65d11aa008f4de "usb: gadget: f_hid: fix: Prevent accessing
released memory"
should be added to linux-4.4.y (it's already in 4.9 and 4.14).
Thanks,
Jerry
If bios sets up an MST output and hardware state readout code sees this is
an SST configuration, when disabling the encoder we end up calling
->post_disable_dp() hook instead of the MST version. Consequently, we write
to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
the MST hub. This results in continuous link training failures which keep
the system busy delaying boot. We could identify bios MST boot discrepancy
and handle it accordingly but a simple way to solve this is to write to the
DP_SET_POWER dpcd for MST too.
v2: Rebased on stable/linux-4.15.y and fixed minor conflict.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Jani Nikula <jani.nikula(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Reported-by: Laura Abbott <labbott(a)redhat.com>
Cc: <stable(a)vger.kernel.org> # 4.15+
Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control")
Tested-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180314054825.1718-1-dhinaka…
(cherry picked from commit ad260ab32a4d94fa974f58262f8000472d34fd5b)
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com>
---
drivers/gpu/drm/i915/intel_ddi.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 58a3755544b2..38e53d6b8127 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2208,8 +2208,7 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
intel_prepare_dp_ddi_buffers(encoder);
intel_ddi_init_dp_buf_reg(encoder);
- if (!is_mst)
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
@@ -2294,19 +2293,12 @@ static void intel_ddi_post_disable_dp(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
struct intel_dp *intel_dp = &dig_port->dp;
- /*
- * old_crtc_state and old_conn_state are NULL when called from
- * DP_MST. The main connector associated with this port is never
- * bound to a crtc for MST.
- */
- bool is_mst = !old_crtc_state;
/*
* Power down sink before disabling the port, otherwise we end
* up getting interrupts from the sink on detecting link loss.
*/
- if (!is_mst)
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_disable_ddi_buf(encoder);
--
2.14.1
This is a note to let you know that I've just added the patch titled
usb: dwc2: Improve gadget state disconnection handling
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-dwc2-improve-gadget-state-disconnection-handling.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d2471d4a24dfbff5e463d382e2c6fec7d7e25a09 Mon Sep 17 00:00:00 2001
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 23 Oct 2017 14:32:48 -0700
Subject: usb: dwc2: Improve gadget state disconnection handling
From: John Stultz <john.stultz(a)linaro.org>
commit d2471d4a24dfbff5e463d382e2c6fec7d7e25a09 upstream.
In the earlier commit dad3f793f20f ("usb: dwc2: Make sure we
disconnect the gadget state"), I was trying to fix up the
fact that we somehow weren't disconnecting the gadget state,
so that when the OTG port was plugged in the second time we
would get warnings about the state tracking being wrong.
(This seems to be due to a quirk of the HiKey board where
we do not ever get any otg interrupts, particularly the session
end detected signal. Instead we only see status change
interrupt.)
The fix there was somewhat simple, as it just made sure to
call dwc2_hsotg_disconnect() before we connected things up
in OTG mode, ensuring the state handling didn't throw errors.
But in looking at a different issue I was seeing with UDC
state handling, I realized that it would be much better
to call dwc2_hsotg_disconnect when we get the state change
signal moving to host mode.
Thus, this patch removes the earlier disconnect call I added
and moves it (and the needed locking) to the host mode
transition.
Cc: Wei Xu <xuwei5(a)hisilicon.com>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: YongQin Liu <yongqin.liu(a)linaro.org>
Cc: John Youn <johnyoun(a)synopsys.com>
Cc: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Cc: Douglas Anderson <dianders(a)chromium.org>
Cc: Chen Yu <chenyu56(a)huawei.com>
Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: linux-usb(a)vger.kernel.org
Acked-by: Minas Harutyunyan <hminas(a)synopsys.com>
Tested-by: Minas Harutyunyan <hminas(a)synopsys.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/hcd.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3220,7 +3220,6 @@ static void dwc2_conn_id_status_change(s
dwc2_core_init(hsotg, false);
dwc2_enable_global_interrupts(hsotg);
spin_lock_irqsave(&hsotg->lock, flags);
- dwc2_hsotg_disconnect(hsotg);
dwc2_hsotg_core_init_disconnected(hsotg, false);
spin_unlock_irqrestore(&hsotg->lock, flags);
dwc2_hsotg_core_connect(hsotg);
@@ -3238,8 +3237,12 @@ static void dwc2_conn_id_status_change(s
if (count > 250)
dev_err(hsotg->dev,
"Connection id status change timed out\n");
- hsotg->op_state = OTG_STATE_A_HOST;
+ spin_lock_irqsave(&hsotg->lock, flags);
+ dwc2_hsotg_disconnect(hsotg);
+ spin_unlock_irqrestore(&hsotg->lock, flags);
+
+ hsotg->op_state = OTG_STATE_A_HOST;
/* Initialize the Core for Host mode */
dwc2_core_init(hsotg, false);
dwc2_enable_global_interrupts(hsotg);
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.9/usb-dwc2-improve-gadget-state-disconnection-handling.patch
This is a note to let you know that I've just added the patch titled
usb: dwc2: Improve gadget state disconnection handling
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-dwc2-improve-gadget-state-disconnection-handling.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d2471d4a24dfbff5e463d382e2c6fec7d7e25a09 Mon Sep 17 00:00:00 2001
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 23 Oct 2017 14:32:48 -0700
Subject: usb: dwc2: Improve gadget state disconnection handling
From: John Stultz <john.stultz(a)linaro.org>
commit d2471d4a24dfbff5e463d382e2c6fec7d7e25a09 upstream.
In the earlier commit dad3f793f20f ("usb: dwc2: Make sure we
disconnect the gadget state"), I was trying to fix up the
fact that we somehow weren't disconnecting the gadget state,
so that when the OTG port was plugged in the second time we
would get warnings about the state tracking being wrong.
(This seems to be due to a quirk of the HiKey board where
we do not ever get any otg interrupts, particularly the session
end detected signal. Instead we only see status change
interrupt.)
The fix there was somewhat simple, as it just made sure to
call dwc2_hsotg_disconnect() before we connected things up
in OTG mode, ensuring the state handling didn't throw errors.
But in looking at a different issue I was seeing with UDC
state handling, I realized that it would be much better
to call dwc2_hsotg_disconnect when we get the state change
signal moving to host mode.
Thus, this patch removes the earlier disconnect call I added
and moves it (and the needed locking) to the host mode
transition.
Cc: Wei Xu <xuwei5(a)hisilicon.com>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: YongQin Liu <yongqin.liu(a)linaro.org>
Cc: John Youn <johnyoun(a)synopsys.com>
Cc: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Cc: Douglas Anderson <dianders(a)chromium.org>
Cc: Chen Yu <chenyu56(a)huawei.com>
Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: linux-usb(a)vger.kernel.org
Acked-by: Minas Harutyunyan <hminas(a)synopsys.com>
Tested-by: Minas Harutyunyan <hminas(a)synopsys.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/hcd.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1385,7 +1385,6 @@ static void dwc2_conn_id_status_change(s
dwc2_core_init(hsotg, false, -1);
dwc2_enable_global_interrupts(hsotg);
spin_lock_irqsave(&hsotg->lock, flags);
- dwc2_hsotg_disconnect(hsotg);
dwc2_hsotg_core_init_disconnected(hsotg, false);
spin_unlock_irqrestore(&hsotg->lock, flags);
dwc2_hsotg_core_connect(hsotg);
@@ -1403,8 +1402,12 @@ static void dwc2_conn_id_status_change(s
if (count > 250)
dev_err(hsotg->dev,
"Connection id status change timed out\n");
- hsotg->op_state = OTG_STATE_A_HOST;
+ spin_lock_irqsave(&hsotg->lock, flags);
+ dwc2_hsotg_disconnect(hsotg);
+ spin_unlock_irqrestore(&hsotg->lock, flags);
+
+ hsotg->op_state = OTG_STATE_A_HOST;
/* Initialize the Core for Host mode */
dwc2_core_init(hsotg, false, -1);
dwc2_enable_global_interrupts(hsotg);
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.4/usb-dwc2-improve-gadget-state-disconnection-handling.patch
This is a note to let you know that I've just added the patch titled
drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-dp-write-to-set_power-dpcd-to-enable-mst-hub.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b1e314462bba76660eec62760bb2e87f28f58866 Mon Sep 17 00:00:00 2001
From: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com>
Date: Tue, 13 Mar 2018 22:48:25 -0700
Subject: drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com>
commit b1e314462bba76660eec62760bb2e87f28f58866 upstream.
If bios sets up an MST output and hardware state readout code sees this is
an SST configuration, when disabling the encoder we end up calling
->post_disable_dp() hook instead of the MST version. Consequently, we write
to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
the MST hub. This results in continuous link training failures which keep
the system busy delaying boot. We could identify bios MST boot discrepancy
and handle it accordingly but a simple way to solve this is to write to the
DP_SET_POWER dpcd for MST too.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Jani Nikula <jani.nikula(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Reported-by: Laura Abbott <labbott(a)redhat.com>
Cc: stable(a)vger.kernel.org
Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control")
Tested-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180314054825.1718-1-dhinaka…
(cherry picked from commit ad260ab32a4d94fa974f58262f8000472d34fd5b)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_ddi.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2208,8 +2208,7 @@ static void intel_ddi_pre_enable_dp(stru
intel_prepare_dp_ddi_buffers(encoder);
intel_ddi_init_dp_buf_reg(encoder);
- if (!is_mst)
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
@@ -2294,19 +2293,12 @@ static void intel_ddi_post_disable_dp(st
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
struct intel_dp *intel_dp = &dig_port->dp;
- /*
- * old_crtc_state and old_conn_state are NULL when called from
- * DP_MST. The main connector associated with this port is never
- * bound to a crtc for MST.
- */
- bool is_mst = !old_crtc_state;
/*
* Power down sink before disabling the port, otherwise we end
* up getting interrupts from the sink on detecting link loss.
*/
- if (!is_mst)
- intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_disable_ddi_buf(encoder);
Patches currently in stable-queue which might be from dhinakaran.pandiyan(a)intel.com are
queue-4.15/drm-i915-dp-write-to-set_power-dpcd-to-enable-mst-hub.patch
This is a note to let you know that I've just added the patch titled
usb: dwc2: Improve gadget state disconnection handling
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-dwc2-improve-gadget-state-disconnection-handling.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d2471d4a24dfbff5e463d382e2c6fec7d7e25a09 Mon Sep 17 00:00:00 2001
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 23 Oct 2017 14:32:48 -0700
Subject: usb: dwc2: Improve gadget state disconnection handling
From: John Stultz <john.stultz(a)linaro.org>
commit d2471d4a24dfbff5e463d382e2c6fec7d7e25a09 upstream.
In the earlier commit dad3f793f20f ("usb: dwc2: Make sure we
disconnect the gadget state"), I was trying to fix up the
fact that we somehow weren't disconnecting the gadget state,
so that when the OTG port was plugged in the second time we
would get warnings about the state tracking being wrong.
(This seems to be due to a quirk of the HiKey board where
we do not ever get any otg interrupts, particularly the session
end detected signal. Instead we only see status change
interrupt.)
The fix there was somewhat simple, as it just made sure to
call dwc2_hsotg_disconnect() before we connected things up
in OTG mode, ensuring the state handling didn't throw errors.
But in looking at a different issue I was seeing with UDC
state handling, I realized that it would be much better
to call dwc2_hsotg_disconnect when we get the state change
signal moving to host mode.
Thus, this patch removes the earlier disconnect call I added
and moves it (and the needed locking) to the host mode
transition.
Cc: Wei Xu <xuwei5(a)hisilicon.com>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: YongQin Liu <yongqin.liu(a)linaro.org>
Cc: John Youn <johnyoun(a)synopsys.com>
Cc: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Cc: Douglas Anderson <dianders(a)chromium.org>
Cc: Chen Yu <chenyu56(a)huawei.com>
Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: linux-usb(a)vger.kernel.org
Acked-by: Minas Harutyunyan <hminas(a)synopsys.com>
Tested-by: Minas Harutyunyan <hminas(a)synopsys.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/hcd.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3277,7 +3277,6 @@ static void dwc2_conn_id_status_change(s
dwc2_core_init(hsotg, false);
dwc2_enable_global_interrupts(hsotg);
spin_lock_irqsave(&hsotg->lock, flags);
- dwc2_hsotg_disconnect(hsotg);
dwc2_hsotg_core_init_disconnected(hsotg, false);
spin_unlock_irqrestore(&hsotg->lock, flags);
dwc2_hsotg_core_connect(hsotg);
@@ -3296,8 +3295,12 @@ host:
if (count > 250)
dev_err(hsotg->dev,
"Connection id status change timed out\n");
- hsotg->op_state = OTG_STATE_A_HOST;
+ spin_lock_irqsave(&hsotg->lock, flags);
+ dwc2_hsotg_disconnect(hsotg);
+ spin_unlock_irqrestore(&hsotg->lock, flags);
+
+ hsotg->op_state = OTG_STATE_A_HOST;
/* Initialize the Core for Host mode */
dwc2_core_init(hsotg, false);
dwc2_enable_global_interrupts(hsotg);
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.14/usb-dwc2-improve-gadget-state-disconnection-handling.patch
This is a note to let you know that I've just added the patch titled
[media] vb2: V4L2_BUF_FLAG_DONE is set after DQBUF
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
vb2-v4l2_buf_flag_done-is-set-after-dqbuf.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3171cc2b4eb9831ab4df1d80d0410a945b8bc84e Mon Sep 17 00:00:00 2001
From: Ricardo Ribalda <ricardo.ribalda(a)gmail.com>
Date: Mon, 20 Jun 2016 09:47:22 -0300
Subject: [media] vb2: V4L2_BUF_FLAG_DONE is set after DQBUF
From: Ricardo Ribalda <ricardo.ribalda(a)gmail.com>
commit 3171cc2b4eb9831ab4df1d80d0410a945b8bc84e upstream.
According to the doc, V4L2_BUF_FLAG_DONE is cleared after DQBUF:
V4L2_BUF_FLAG_DONE 0x00000004 ... After calling the VIDIOC_QBUF or
VIDIOC_DQBUF it is always cleared ...
Unfortunately, it seems that videobuf2 keeps it set after DQBUF. This
can be tested with vivid and dev_debug:
[257604.338082] video1: VIDIOC_DQBUF: 71:33:25.00260479 index=3,
type=vid-cap, flags=0x00002004, field=none, sequence=163,
memory=userptr, bytesused=460800, offset/userptr=0x344b000,
length=460800
This patch forces FLAG_DONE to 0 after calling DQBUF.
Reported-by: Dimitrios Katsaros <patcherwork(a)gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/videobuf2-core.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2075,6 +2075,11 @@ static int vb2_internal_dqbuf(struct vb2
dprintk(1, "dqbuf of buffer %d, with state %d\n",
vb->v4l2_buf.index, vb->state);
+ /*
+ * After calling the VIDIOC_DQBUF V4L2_BUF_FLAG_DONE must be
+ * cleared.
+ */
+ b->flags &= ~V4L2_BUF_FLAG_DONE;
return 0;
}
Patches currently in stable-queue which might be from ricardo.ribalda(a)gmail.com are
queue-3.18/vb2-v4l2_buf_flag_done-is-set-after-dqbuf.patch
This is a note to let you know that I've just added the patch titled
media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 181a4a2d5a0a7b43cab08a70710d727e7764ccdd Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Tue, 30 Jan 2018 03:50:01 -0500
Subject: media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
From: Hans Verkuil <hans.verkuil(a)cisco.com>
commit 181a4a2d5a0a7b43cab08a70710d727e7764ccdd upstream.
If the ioctl returned -ENOTTY, then don't bother copying
back the result as there is no point.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # for v4.15 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-ioctl.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2539,8 +2539,11 @@ video_usercopy(struct file *file, unsign
/* Handles IOCTL */
err = func(file, cmd, parg);
- if (err == -ENOIOCTLCMD)
+ if (err == -ENOTTY || err == -ENOIOCTLCMD) {
err = -ENOTTY;
+ goto out;
+ }
+
if (err == 0) {
if (cmd == VIDIOC_DQBUF)
trace_v4l2_dqbuf(video_devdata(file)->minor, parg);
Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are
queue-3.18/vb2-v4l2_buf_flag_done-is-set-after-dqbuf.patch
queue-3.18/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
This is a note to let you know that I've just added the patch titled
scsi: virtio_scsi: always read VPD pages for multiqueue too
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-virtio_scsi-always-read-vpd-pages-for-multiqueue-too.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a680f1d463aeaeb00d22af257a56e111967c2f18 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Wed, 5 Jul 2017 10:30:56 +0200
Subject: scsi: virtio_scsi: always read VPD pages for multiqueue too
From: Paolo Bonzini <pbonzini(a)redhat.com>
commit a680f1d463aeaeb00d22af257a56e111967c2f18 upstream.
Multi-queue virtio-scsi uses a different scsi_host_template struct. Add
the .device_alloc field there, too.
Fixes: 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0
Cc: stable(a)vger.kernel.org
Cc: David Gibson <david(a)gibson.dropbear.id.au>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Reviewed-by: Fam Zheng <famz(a)redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/virtio_scsi.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -819,6 +819,7 @@ static struct scsi_host_template virtscs
.change_queue_depth = virtscsi_change_queue_depth,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
+ .slave_alloc = virtscsi_device_alloc,
.can_queue = 1024,
.dma_boundary = UINT_MAX,
Patches currently in stable-queue which might be from pbonzini(a)redhat.com are
queue-4.9/scsi-virtio_scsi-always-read-vpd-pages-for-multiqueue-too.patch
This is a note to let you know that I've just added the patch titled
scsi: virtio_scsi: always read VPD pages for multiqueue too
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-virtio_scsi-always-read-vpd-pages-for-multiqueue-too.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a680f1d463aeaeb00d22af257a56e111967c2f18 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Wed, 5 Jul 2017 10:30:56 +0200
Subject: scsi: virtio_scsi: always read VPD pages for multiqueue too
From: Paolo Bonzini <pbonzini(a)redhat.com>
commit a680f1d463aeaeb00d22af257a56e111967c2f18 upstream.
Multi-queue virtio-scsi uses a different scsi_host_template struct. Add
the .device_alloc field there, too.
Fixes: 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0
Cc: stable(a)vger.kernel.org
Cc: David Gibson <david(a)gibson.dropbear.id.au>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Reviewed-by: Fam Zheng <famz(a)redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/virtio_scsi.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -819,6 +819,7 @@ static struct scsi_host_template virtscs
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
+ .slave_alloc = virtscsi_device_alloc,
.can_queue = 1024,
.dma_boundary = UINT_MAX,
.use_clustering = ENABLE_CLUSTERING,
Patches currently in stable-queue which might be from pbonzini(a)redhat.com are
queue-4.4/scsi-virtio_scsi-always-read-vpd-pages-for-multiqueue-too.patch
This is a note to let you know that I've just added the patch titled
scsi: virtio_scsi: always read VPD pages for multiqueue too
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-virtio_scsi-always-read-vpd-pages-for-multiqueue-too.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a680f1d463aeaeb00d22af257a56e111967c2f18 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini(a)redhat.com>
Date: Wed, 5 Jul 2017 10:30:56 +0200
Subject: scsi: virtio_scsi: always read VPD pages for multiqueue too
From: Paolo Bonzini <pbonzini(a)redhat.com>
commit a680f1d463aeaeb00d22af257a56e111967c2f18 upstream.
Multi-queue virtio-scsi uses a different scsi_host_template struct. Add
the .device_alloc field there, too.
Fixes: 25d1d50e23275e141e3a3fe06c25a99f4c4bf4e0
Cc: stable(a)vger.kernel.org
Cc: David Gibson <david(a)gibson.dropbear.id.au>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Reviewed-by: Fam Zheng <famz(a)redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/virtio_scsi.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -794,6 +794,7 @@ static struct scsi_host_template virtscs
.change_queue_depth = virtscsi_change_queue_depth,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
+ .slave_alloc = virtscsi_device_alloc,
.can_queue = 1024,
.dma_boundary = UINT_MAX,
Patches currently in stable-queue which might be from pbonzini(a)redhat.com are
queue-3.18/scsi-virtio_scsi-always-read-vpd-pages-for-multiqueue-too.patch
queue-3.18/kvm-x86-fix-icebp-instruction-handling.patch
This is a note to let you know that I've just added the patch titled
llist: clang: introduce member_address_is_nonnull()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
llist-clang-introduce-member_address_is_nonnull.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From beaec533fc2701a28a4d667f67c9f59c6e4e0d13 Mon Sep 17 00:00:00 2001
From: Alexander Potapenko <glider(a)google.com>
Date: Wed, 19 Jul 2017 20:27:30 +0200
Subject: llist: clang: introduce member_address_is_nonnull()
From: Alexander Potapenko <glider(a)google.com>
commit beaec533fc2701a28a4d667f67c9f59c6e4e0d13 upstream.
Currently llist_for_each_entry() and llist_for_each_entry_safe() iterate
until &pos->member != NULL. But when building the kernel with Clang,
the compiler assumes &pos->member cannot be NULL if the member's offset
is greater than 0 (which would be equivalent to the object being
non-contiguous in memory). Therefore the loop condition is always true,
and the loops become infinite.
To work around this, introduce the member_address_is_nonnull() macro,
which casts object pointer to uintptr_t, thus letting the member pointer
to be NULL.
Signed-off-by: Alexander Potapenko <glider(a)google.com>
Tested-by: Sodagudi Prasad <psodagud(a)codeaurora.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/llist.h | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -88,6 +88,23 @@ static inline void init_llist_head(struc
container_of(ptr, type, member)
/**
+ * member_address_is_nonnull - check whether the member address is not NULL
+ * @ptr: the object pointer (struct type * that contains the llist_node)
+ * @member: the name of the llist_node within the struct.
+ *
+ * This macro is conceptually the same as
+ * &ptr->member != NULL
+ * but it works around the fact that compilers can decide that taking a member
+ * address is never a NULL pointer.
+ *
+ * Real objects that start at a high address and have a member at NULL are
+ * unlikely to exist, but such pointers may be returned e.g. by the
+ * container_of() macro.
+ */
+#define member_address_is_nonnull(ptr, member) \
+ ((uintptr_t)(ptr) + offsetof(typeof(*(ptr)), member) != 0)
+
+/**
* llist_for_each - iterate over some deleted entries of a lock-less list
* @pos: the &struct llist_node to use as a loop cursor
* @node: the first entry of deleted list entries
@@ -121,7 +138,7 @@ static inline void init_llist_head(struc
*/
#define llist_for_each_entry(pos, node, member) \
for ((pos) = llist_entry((node), typeof(*(pos)), member); \
- &(pos)->member != NULL; \
+ member_address_is_nonnull(pos, member); \
(pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))
/**
@@ -143,7 +160,7 @@ static inline void init_llist_head(struc
*/
#define llist_for_each_entry_safe(pos, n, node, member) \
for (pos = llist_entry((node), typeof(*pos), member); \
- &pos->member != NULL && \
+ member_address_is_nonnull(pos, member) && \
(n = llist_entry(pos->member.next, typeof(*n), member), true); \
pos = n)
Patches currently in stable-queue which might be from glider(a)google.com are
queue-4.9/llist-clang-introduce-member_address_is_nonnull.patch
This is a note to let you know that I've just added the patch titled
llist: clang: introduce member_address_is_nonnull()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
llist-clang-introduce-member_address_is_nonnull.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From beaec533fc2701a28a4d667f67c9f59c6e4e0d13 Mon Sep 17 00:00:00 2001
From: Alexander Potapenko <glider(a)google.com>
Date: Wed, 19 Jul 2017 20:27:30 +0200
Subject: llist: clang: introduce member_address_is_nonnull()
From: Alexander Potapenko <glider(a)google.com>
commit beaec533fc2701a28a4d667f67c9f59c6e4e0d13 upstream.
Currently llist_for_each_entry() and llist_for_each_entry_safe() iterate
until &pos->member != NULL. But when building the kernel with Clang,
the compiler assumes &pos->member cannot be NULL if the member's offset
is greater than 0 (which would be equivalent to the object being
non-contiguous in memory). Therefore the loop condition is always true,
and the loops become infinite.
To work around this, introduce the member_address_is_nonnull() macro,
which casts object pointer to uintptr_t, thus letting the member pointer
to be NULL.
Signed-off-by: Alexander Potapenko <glider(a)google.com>
Tested-by: Sodagudi Prasad <psodagud(a)codeaurora.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/llist.h | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -88,6 +88,23 @@ static inline void init_llist_head(struc
container_of(ptr, type, member)
/**
+ * member_address_is_nonnull - check whether the member address is not NULL
+ * @ptr: the object pointer (struct type * that contains the llist_node)
+ * @member: the name of the llist_node within the struct.
+ *
+ * This macro is conceptually the same as
+ * &ptr->member != NULL
+ * but it works around the fact that compilers can decide that taking a member
+ * address is never a NULL pointer.
+ *
+ * Real objects that start at a high address and have a member at NULL are
+ * unlikely to exist, but such pointers may be returned e.g. by the
+ * container_of() macro.
+ */
+#define member_address_is_nonnull(ptr, member) \
+ ((uintptr_t)(ptr) + offsetof(typeof(*(ptr)), member) != 0)
+
+/**
* llist_for_each - iterate over some deleted entries of a lock-less list
* @pos: the &struct llist_node to use as a loop cursor
* @node: the first entry of deleted list entries
@@ -121,7 +138,7 @@ static inline void init_llist_head(struc
*/
#define llist_for_each_entry(pos, node, member) \
for ((pos) = llist_entry((node), typeof(*(pos)), member); \
- &(pos)->member != NULL; \
+ member_address_is_nonnull(pos, member); \
(pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))
/**
@@ -143,7 +160,7 @@ static inline void init_llist_head(struc
*/
#define llist_for_each_entry_safe(pos, n, node, member) \
for (pos = llist_entry((node), typeof(*pos), member); \
- &pos->member != NULL && \
+ member_address_is_nonnull(pos, member) && \
(n = llist_entry(pos->member.next, typeof(*n), member), true); \
pos = n)
Patches currently in stable-queue which might be from glider(a)google.com are
queue-4.4/llist-clang-introduce-member_address_is_nonnull.patch
This is a note to let you know that I've just added the patch titled
xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 19d7df69fdb2636856dc8919de72fc1bf8f79598 Mon Sep 17 00:00:00 2001
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Thu, 1 Feb 2018 08:49:23 +0100
Subject: xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
From: Steffen Klassert <steffen.klassert(a)secunet.com>
commit 19d7df69fdb2636856dc8919de72fc1bf8f79598 upstream.
We don't have a compat layer for xfrm, so userspace and kernel
structures have different sizes in this case. This results in
a broken configuration, so refuse to configure socket policies
when trying to insert from 32 bit userspace as we do it already
with policies inserted via netlink.
Reported-and-tested-by: syzbot+e1a1577ca8bcb47b769a(a)syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_state.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1883,6 +1883,11 @@ int xfrm_user_policy(struct sock *sk, in
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;
+#ifdef CONFIG_COMPAT
+ if (in_compat_syscall())
+ return -EOPNOTSUPP;
+#endif
+
if (!optval && !optlen) {
xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-4.9/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.9/xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
queue-4.9/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: add and use xt_check_proc_name
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-x_tables-add-and-use-xt_check_proc_name.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b1d0a5d0cba4597c0394997b2d5fced3e3841b4e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Sat, 10 Mar 2018 01:15:45 +0100
Subject: netfilter: x_tables: add and use xt_check_proc_name
From: Florian Westphal <fw(a)strlen.de>
commit b1d0a5d0cba4597c0394997b2d5fced3e3841b4e upstream.
recent and hashlimit both create /proc files, but only check that
name is 0 terminated.
This can trigger WARN() from procfs when name is "" or "/".
Add helper for this and then use it for both.
Cc: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: <syzbot+0502b00edac2a0680b61(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/netfilter/x_tables.h | 2 ++
net/netfilter/x_tables.c | 30 ++++++++++++++++++++++++++++++
net/netfilter/xt_hashlimit.c | 11 +++++++----
net/netfilter/xt_recent.c | 6 +++---
4 files changed, 42 insertions(+), 7 deletions(-)
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -254,6 +254,8 @@ unsigned int *xt_alloc_entry_offsets(uns
bool xt_find_jump_offset(const unsigned int *offsets,
unsigned int target, unsigned int size);
+int xt_check_proc_name(const char *name, unsigned int size);
+
int xt_check_match(struct xt_mtchk_param *, unsigned int size, u_int8_t proto,
bool inv_proto);
int xt_check_target(struct xt_tgchk_param *, unsigned int size, u_int8_t proto,
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -367,6 +367,36 @@ textify_hooks(char *buf, size_t size, un
return buf;
}
+/**
+ * xt_check_proc_name - check that name is suitable for /proc file creation
+ *
+ * @name: file name candidate
+ * @size: length of buffer
+ *
+ * some x_tables modules wish to create a file in /proc.
+ * This function makes sure that the name is suitable for this
+ * purpose, it checks that name is NUL terminated and isn't a 'special'
+ * name, like "..".
+ *
+ * returns negative number on error or 0 if name is useable.
+ */
+int xt_check_proc_name(const char *name, unsigned int size)
+{
+ if (name[0] == '\0')
+ return -EINVAL;
+
+ if (strnlen(name, size) == size)
+ return -ENAMETOOLONG;
+
+ if (strcmp(name, ".") == 0 ||
+ strcmp(name, "..") == 0 ||
+ strchr(name, '/'))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(xt_check_proc_name);
+
int xt_check_match(struct xt_mtchk_param *par,
unsigned int size, u_int8_t proto, bool inv_proto)
{
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -794,8 +794,9 @@ static int hashlimit_mt_check_v1(const s
struct hashlimit_cfg2 cfg = {};
int ret;
- if (info->name[sizeof(info->name) - 1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
ret = cfg_copy(&cfg, (void *)&info->cfg, 1);
@@ -809,9 +810,11 @@ static int hashlimit_mt_check_v1(const s
static int hashlimit_mt_check(const struct xt_mtchk_param *par)
{
struct xt_hashlimit_mtinfo2 *info = par->matchinfo;
+ int ret;
- if (info->name[sizeof(info->name) - 1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
return hashlimit_mt_check_common(par, &info->hinfo, &info->cfg,
info->name, 2);
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -361,9 +361,9 @@ static int recent_mt_check(const struct
info->hit_count, XT_RECENT_MAX_NSTAMPS - 1);
return -EINVAL;
}
- if (info->name[0] == '\0' ||
- strnlen(info->name, XT_RECENT_NAME_LEN) == XT_RECENT_NAME_LEN)
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
if (ip_pkt_list_tot && info->hit_count < ip_pkt_list_tot)
nstamp_mask = roundup_pow_of_two(ip_pkt_list_tot) - 1;
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.9/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-4.9/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.9/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
queue-4.9/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
netfilter: bridge: ebt_among: add more missing match size checks
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Fri, 9 Mar 2018 14:27:31 +0100
Subject: netfilter: bridge: ebt_among: add more missing match size checks
From: Florian Westphal <fw(a)strlen.de>
commit c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 upstream.
ebt_among is special, it has a dynamic match size and is exempt
from the central size checks.
commit c4585a2823edf ("bridge: ebt_among: add missing match size checks")
added validation for pool size, but missed fact that the macros
ebt_among_wh_src/dst can already return out-of-bound result because
they do not check value of wh_src/dst_ofs (an offset) vs. the size
of the match that userspace gave to us.
v2:
check that offset has correct alignment.
Paolo Abeni points out that we should also check that src/dst
wormhash arrays do not overlap, and src + length lines up with
start of dst (or vice versa).
v3: compact wormhash_sizes_valid() part
NB: Fixes tag is intentionally wrong, this bug exists from day
one when match was added for 2.6 kernel. Tag is there so stable
maintainers will notice this one too.
Tested with same rules from the earlier patch.
Fixes: c4585a2823edf ("bridge: ebt_among: add missing match size checks")
Reported-by: <syzbot+bdabab6f1983a03fc009(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bridge/netfilter/ebt_among.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
--- a/net/bridge/netfilter/ebt_among.c
+++ b/net/bridge/netfilter/ebt_among.c
@@ -177,6 +177,28 @@ static bool poolsize_invalid(const struc
return w && w->poolsize >= (INT_MAX / sizeof(struct ebt_mac_wormhash_tuple));
}
+static bool wormhash_offset_invalid(int off, unsigned int len)
+{
+ if (off == 0) /* not present */
+ return false;
+
+ if (off < (int)sizeof(struct ebt_among_info) ||
+ off % __alignof__(struct ebt_mac_wormhash))
+ return true;
+
+ off += sizeof(struct ebt_mac_wormhash);
+
+ return off > len;
+}
+
+static bool wormhash_sizes_valid(const struct ebt_mac_wormhash *wh, int a, int b)
+{
+ if (a == 0)
+ a = sizeof(struct ebt_among_info);
+
+ return ebt_mac_wormhash_size(wh) + a == b;
+}
+
static int ebt_among_mt_check(const struct xt_mtchk_param *par)
{
const struct ebt_among_info *info = par->matchinfo;
@@ -189,6 +211,10 @@ static int ebt_among_mt_check(const stru
if (expected_length > em->match_size)
return -EINVAL;
+ if (wormhash_offset_invalid(info->wh_dst_ofs, em->match_size) ||
+ wormhash_offset_invalid(info->wh_src_ofs, em->match_size))
+ return -EINVAL;
+
wh_dst = ebt_among_wh_dst(info);
if (poolsize_invalid(wh_dst))
return -EINVAL;
@@ -201,6 +227,14 @@ static int ebt_among_mt_check(const stru
if (poolsize_invalid(wh_src))
return -EINVAL;
+ if (info->wh_src_ofs < info->wh_dst_ofs) {
+ if (!wormhash_sizes_valid(wh_src, info->wh_src_ofs, info->wh_dst_ofs))
+ return -EINVAL;
+ } else {
+ if (!wormhash_sizes_valid(wh_dst, info->wh_dst_ofs, info->wh_src_ofs))
+ return -EINVAL;
+ }
+
expected_length += ebt_mac_wormhash_size(wh_src);
if (em->match_size != EBT_ALIGN(expected_length)) {
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.9/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-4.9/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.9/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
queue-4.9/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0dcd7876029b58770f769cbb7b484e88e4a305e5 Mon Sep 17 00:00:00 2001
From: Greg Hackmann <ghackmann(a)google.com>
Date: Wed, 7 Mar 2018 14:42:53 -0800
Subject: net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
From: Greg Hackmann <ghackmann(a)google.com>
commit 0dcd7876029b58770f769cbb7b484e88e4a305e5 upstream.
f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
__this_cpu_read() call inside ipcomp_alloc_tfms().
At the time, __this_cpu_read() required the caller to either not care
about races or to handle preemption/interrupt issues. 3.15 tightened
the rules around some per-cpu operations, and now __this_cpu_read()
should never be used in a preemptible context. On 3.15 and later, we
need to use this_cpu_read() instead.
syzkaller reported this leading to the following kernel BUG while
fuzzing sendmsg:
BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101
caller is ipcomp_init_state+0x185/0x990
CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 #154
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Call Trace:
dump_stack+0xb9/0x115
check_preemption_disabled+0x1cb/0x1f0
ipcomp_init_state+0x185/0x990
? __xfrm_init_state+0x876/0xc20
? lock_downgrade+0x5e0/0x5e0
ipcomp4_init_state+0xaa/0x7c0
__xfrm_init_state+0x3eb/0xc20
xfrm_init_state+0x19/0x60
pfkey_add+0x20df/0x36f0
? pfkey_broadcast+0x3dd/0x600
? pfkey_sock_destruct+0x340/0x340
? pfkey_seq_stop+0x80/0x80
? __skb_clone+0x236/0x750
? kmem_cache_alloc+0x1f6/0x260
? pfkey_sock_destruct+0x340/0x340
? pfkey_process+0x62a/0x6f0
pfkey_process+0x62a/0x6f0
? pfkey_send_new_mapping+0x11c0/0x11c0
? mutex_lock_io_nested+0x1390/0x1390
pfkey_sendmsg+0x383/0x750
? dump_sp+0x430/0x430
sock_sendmsg+0xc0/0x100
___sys_sendmsg+0x6c8/0x8b0
? copy_msghdr_from_user+0x3b0/0x3b0
? pagevec_lru_move_fn+0x144/0x1f0
? find_held_lock+0x32/0x1c0
? do_huge_pmd_anonymous_page+0xc43/0x11e0
? lock_downgrade+0x5e0/0x5e0
? get_kernel_page+0xb0/0xb0
? _raw_spin_unlock+0x29/0x40
? do_huge_pmd_anonymous_page+0x400/0x11e0
? __handle_mm_fault+0x553/0x2460
? __fget_light+0x163/0x1f0
? __sys_sendmsg+0xc7/0x170
__sys_sendmsg+0xc7/0x170
? SyS_shutdown+0x1a0/0x1a0
? __do_page_fault+0x5a0/0xca0
? lock_downgrade+0x5e0/0x5e0
SyS_sendmsg+0x27/0x40
? __sys_sendmsg+0x170/0x170
do_syscall_64+0x19f/0x640
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x7f0ee73dfb79
RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79
RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004
RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0
R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440
R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000
Signed-off-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_ipcomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -283,7 +283,7 @@ static struct crypto_comp * __percpu *ip
struct crypto_comp *tfm;
/* This can be any valid CPU ID so we don't need locking. */
- tfm = __this_cpu_read(*pos->tfms);
+ tfm = this_cpu_read(*pos->tfms);
if (!strcmp(crypto_comp_name(tfm), alg_name)) {
pos->users++;
Patches currently in stable-queue which might be from ghackmann(a)google.com are
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: Fix missing encryption refresh on Security Request
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-fix-missing-encryption-refresh-on-security-request.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 64e759f58f128730b97a3c3a26d283c075ad7c86 Mon Sep 17 00:00:00 2001
From: Szymon Janc <szymon.janc(a)codecoup.pl>
Date: Mon, 26 Feb 2018 15:41:53 +0100
Subject: Bluetooth: Fix missing encryption refresh on Security Request
From: Szymon Janc <szymon.janc(a)codecoup.pl>
commit 64e759f58f128730b97a3c3a26d283c075ad7c86 upstream.
If Security Request is received on connection that is already encrypted
with sufficient security master should perform encryption key refresh
procedure instead of just ignoring Slave Security Request
(Core Spec 5.0 Vol 3 Part H 2.4.6).
> ACL Data RX: Handle 3585 flags 0x02 dlen 6
SMP: Security Request (0x0b) len 1
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28
Handle: 3585
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
Long term key: 44264272a5c426a9e868f034cf0e69f3
> HCI Event: Command Status (0x0f) plen 4
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Encryption Key Refresh Complete (0x30) plen 3
Status: Success (0x00)
Handle: 3585
Signed-off-by: Szymon Janc <szymon.janc(a)codecoup.pl>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bluetooth/smp.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2233,8 +2233,14 @@ static u8 smp_cmd_security_req(struct l2
else
sec_level = authreq_to_seclevel(auth);
- if (smp_sufficient_security(hcon, sec_level, SMP_USE_LTK))
+ if (smp_sufficient_security(hcon, sec_level, SMP_USE_LTK)) {
+ /* If link is already encrypted with sufficient security we
+ * still need refresh encryption as per Core Spec 5.0 Vol 3,
+ * Part H 2.4.6
+ */
+ smp_ltk_encrypt(conn, hcon->sec_level);
return 0;
+ }
if (sec_level > hcon->pending_sec_level)
hcon->pending_sec_level = sec_level;
Patches currently in stable-queue which might be from szymon.janc(a)codecoup.pl are
queue-4.9/bluetooth-fix-missing-encryption-refresh-on-security-request.patch
This is a note to let you know that I've just added the patch titled
xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 19d7df69fdb2636856dc8919de72fc1bf8f79598 Mon Sep 17 00:00:00 2001
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Thu, 1 Feb 2018 08:49:23 +0100
Subject: xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
From: Steffen Klassert <steffen.klassert(a)secunet.com>
commit 19d7df69fdb2636856dc8919de72fc1bf8f79598 upstream.
We don't have a compat layer for xfrm, so userspace and kernel
structures have different sizes in this case. This results in
a broken configuration, so refuse to configure socket policies
when trying to insert from 32 bit userspace as we do it already
with policies inserted via netlink.
Reported-and-tested-by: syzbot+e1a1577ca8bcb47b769a(a)syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
[use is_compat_task() - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_state.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1845,6 +1845,11 @@ int xfrm_user_policy(struct sock *sk, in
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;
+#ifdef CONFIG_COMPAT
+ if (is_compat_task())
+ return -EOPNOTSUPP;
+#endif
+
if (!optval && !optlen) {
xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-4.4/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.4/xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
queue-4.4/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: add and use xt_check_proc_name
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-x_tables-add-and-use-xt_check_proc_name.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b1d0a5d0cba4597c0394997b2d5fced3e3841b4e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Sat, 10 Mar 2018 01:15:45 +0100
Subject: netfilter: x_tables: add and use xt_check_proc_name
From: Florian Westphal <fw(a)strlen.de>
commit b1d0a5d0cba4597c0394997b2d5fced3e3841b4e upstream.
recent and hashlimit both create /proc files, but only check that
name is 0 terminated.
This can trigger WARN() from procfs when name is "" or "/".
Add helper for this and then use it for both.
Cc: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: <syzbot+0502b00edac2a0680b61(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/netfilter/x_tables.h | 2 ++
net/netfilter/x_tables.c | 30 ++++++++++++++++++++++++++++++
net/netfilter/xt_hashlimit.c | 5 +++--
net/netfilter/xt_recent.c | 6 +++---
4 files changed, 38 insertions(+), 5 deletions(-)
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -247,6 +247,8 @@ unsigned int *xt_alloc_entry_offsets(uns
bool xt_find_jump_offset(const unsigned int *offsets,
unsigned int target, unsigned int size);
+int xt_check_proc_name(const char *name, unsigned int size);
+
int xt_check_match(struct xt_mtchk_param *, unsigned int size, u_int8_t proto,
bool inv_proto);
int xt_check_target(struct xt_tgchk_param *, unsigned int size, u_int8_t proto,
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -366,6 +366,36 @@ textify_hooks(char *buf, size_t size, un
return buf;
}
+/**
+ * xt_check_proc_name - check that name is suitable for /proc file creation
+ *
+ * @name: file name candidate
+ * @size: length of buffer
+ *
+ * some x_tables modules wish to create a file in /proc.
+ * This function makes sure that the name is suitable for this
+ * purpose, it checks that name is NUL terminated and isn't a 'special'
+ * name, like "..".
+ *
+ * returns negative number on error or 0 if name is useable.
+ */
+int xt_check_proc_name(const char *name, unsigned int size)
+{
+ if (name[0] == '\0')
+ return -EINVAL;
+
+ if (strnlen(name, size) == size)
+ return -ENAMETOOLONG;
+
+ if (strcmp(name, ".") == 0 ||
+ strcmp(name, "..") == 0 ||
+ strchr(name, '/'))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(xt_check_proc_name);
+
int xt_check_match(struct xt_mtchk_param *par,
unsigned int size, u_int8_t proto, bool inv_proto)
{
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -668,8 +668,9 @@ static int hashlimit_mt_check(const stru
if (info->cfg.gc_interval == 0 || info->cfg.expire == 0)
return -EINVAL;
- if (info->name[sizeof(info->name)-1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
if (par->family == NFPROTO_IPV4) {
if (info->cfg.srcmask > 32 || info->cfg.dstmask > 32)
return -EINVAL;
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -364,9 +364,9 @@ static int recent_mt_check(const struct
info->hit_count, XT_RECENT_MAX_NSTAMPS - 1);
return -EINVAL;
}
- if (info->name[0] == '\0' ||
- strnlen(info->name, XT_RECENT_NAME_LEN) == XT_RECENT_NAME_LEN)
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
if (ip_pkt_list_tot && info->hit_count < ip_pkt_list_tot)
nstamp_mask = roundup_pow_of_two(ip_pkt_list_tot) - 1;
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.4/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-4.4/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.4/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
queue-4.4/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
netfilter: bridge: ebt_among: add more missing match size checks
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Fri, 9 Mar 2018 14:27:31 +0100
Subject: netfilter: bridge: ebt_among: add more missing match size checks
From: Florian Westphal <fw(a)strlen.de>
commit c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 upstream.
ebt_among is special, it has a dynamic match size and is exempt
from the central size checks.
commit c4585a2823edf ("bridge: ebt_among: add missing match size checks")
added validation for pool size, but missed fact that the macros
ebt_among_wh_src/dst can already return out-of-bound result because
they do not check value of wh_src/dst_ofs (an offset) vs. the size
of the match that userspace gave to us.
v2:
check that offset has correct alignment.
Paolo Abeni points out that we should also check that src/dst
wormhash arrays do not overlap, and src + length lines up with
start of dst (or vice versa).
v3: compact wormhash_sizes_valid() part
NB: Fixes tag is intentionally wrong, this bug exists from day
one when match was added for 2.6 kernel. Tag is there so stable
maintainers will notice this one too.
Tested with same rules from the earlier patch.
Fixes: c4585a2823edf ("bridge: ebt_among: add missing match size checks")
Reported-by: <syzbot+bdabab6f1983a03fc009(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bridge/netfilter/ebt_among.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
--- a/net/bridge/netfilter/ebt_among.c
+++ b/net/bridge/netfilter/ebt_among.c
@@ -177,6 +177,28 @@ static bool poolsize_invalid(const struc
return w && w->poolsize >= (INT_MAX / sizeof(struct ebt_mac_wormhash_tuple));
}
+static bool wormhash_offset_invalid(int off, unsigned int len)
+{
+ if (off == 0) /* not present */
+ return false;
+
+ if (off < (int)sizeof(struct ebt_among_info) ||
+ off % __alignof__(struct ebt_mac_wormhash))
+ return true;
+
+ off += sizeof(struct ebt_mac_wormhash);
+
+ return off > len;
+}
+
+static bool wormhash_sizes_valid(const struct ebt_mac_wormhash *wh, int a, int b)
+{
+ if (a == 0)
+ a = sizeof(struct ebt_among_info);
+
+ return ebt_mac_wormhash_size(wh) + a == b;
+}
+
static int ebt_among_mt_check(const struct xt_mtchk_param *par)
{
const struct ebt_among_info *info = par->matchinfo;
@@ -189,6 +211,10 @@ static int ebt_among_mt_check(const stru
if (expected_length > em->match_size)
return -EINVAL;
+ if (wormhash_offset_invalid(info->wh_dst_ofs, em->match_size) ||
+ wormhash_offset_invalid(info->wh_src_ofs, em->match_size))
+ return -EINVAL;
+
wh_dst = ebt_among_wh_dst(info);
if (poolsize_invalid(wh_dst))
return -EINVAL;
@@ -201,6 +227,14 @@ static int ebt_among_mt_check(const stru
if (poolsize_invalid(wh_src))
return -EINVAL;
+ if (info->wh_src_ofs < info->wh_dst_ofs) {
+ if (!wormhash_sizes_valid(wh_src, info->wh_src_ofs, info->wh_dst_ofs))
+ return -EINVAL;
+ } else {
+ if (!wormhash_sizes_valid(wh_dst, info->wh_dst_ofs, info->wh_src_ofs))
+ return -EINVAL;
+ }
+
expected_length += ebt_mac_wormhash_size(wh_src);
if (em->match_size != EBT_ALIGN(expected_length)) {
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.4/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-4.4/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.4/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
queue-4.4/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0dcd7876029b58770f769cbb7b484e88e4a305e5 Mon Sep 17 00:00:00 2001
From: Greg Hackmann <ghackmann(a)google.com>
Date: Wed, 7 Mar 2018 14:42:53 -0800
Subject: net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
From: Greg Hackmann <ghackmann(a)google.com>
commit 0dcd7876029b58770f769cbb7b484e88e4a305e5 upstream.
f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
__this_cpu_read() call inside ipcomp_alloc_tfms().
At the time, __this_cpu_read() required the caller to either not care
about races or to handle preemption/interrupt issues. 3.15 tightened
the rules around some per-cpu operations, and now __this_cpu_read()
should never be used in a preemptible context. On 3.15 and later, we
need to use this_cpu_read() instead.
syzkaller reported this leading to the following kernel BUG while
fuzzing sendmsg:
BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101
caller is ipcomp_init_state+0x185/0x990
CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 #154
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Call Trace:
dump_stack+0xb9/0x115
check_preemption_disabled+0x1cb/0x1f0
ipcomp_init_state+0x185/0x990
? __xfrm_init_state+0x876/0xc20
? lock_downgrade+0x5e0/0x5e0
ipcomp4_init_state+0xaa/0x7c0
__xfrm_init_state+0x3eb/0xc20
xfrm_init_state+0x19/0x60
pfkey_add+0x20df/0x36f0
? pfkey_broadcast+0x3dd/0x600
? pfkey_sock_destruct+0x340/0x340
? pfkey_seq_stop+0x80/0x80
? __skb_clone+0x236/0x750
? kmem_cache_alloc+0x1f6/0x260
? pfkey_sock_destruct+0x340/0x340
? pfkey_process+0x62a/0x6f0
pfkey_process+0x62a/0x6f0
? pfkey_send_new_mapping+0x11c0/0x11c0
? mutex_lock_io_nested+0x1390/0x1390
pfkey_sendmsg+0x383/0x750
? dump_sp+0x430/0x430
sock_sendmsg+0xc0/0x100
___sys_sendmsg+0x6c8/0x8b0
? copy_msghdr_from_user+0x3b0/0x3b0
? pagevec_lru_move_fn+0x144/0x1f0
? find_held_lock+0x32/0x1c0
? do_huge_pmd_anonymous_page+0xc43/0x11e0
? lock_downgrade+0x5e0/0x5e0
? get_kernel_page+0xb0/0xb0
? _raw_spin_unlock+0x29/0x40
? do_huge_pmd_anonymous_page+0x400/0x11e0
? __handle_mm_fault+0x553/0x2460
? __fget_light+0x163/0x1f0
? __sys_sendmsg+0xc7/0x170
__sys_sendmsg+0xc7/0x170
? SyS_shutdown+0x1a0/0x1a0
? __do_page_fault+0x5a0/0xca0
? lock_downgrade+0x5e0/0x5e0
SyS_sendmsg+0x27/0x40
? __sys_sendmsg+0x170/0x170
do_syscall_64+0x19f/0x640
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x7f0ee73dfb79
RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79
RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004
RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0
R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440
R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000
Signed-off-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_ipcomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -283,7 +283,7 @@ static struct crypto_comp * __percpu *ip
struct crypto_comp *tfm;
/* This can be any valid CPU ID so we don't need locking. */
- tfm = __this_cpu_read(*pos->tfms);
+ tfm = this_cpu_read(*pos->tfms);
if (!strcmp(crypto_comp_name(tfm), alg_name)) {
pos->users++;
Patches currently in stable-queue which might be from ghackmann(a)google.com are
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.4/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: Fix missing encryption refresh on Security Request
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-fix-missing-encryption-refresh-on-security-request.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 64e759f58f128730b97a3c3a26d283c075ad7c86 Mon Sep 17 00:00:00 2001
From: Szymon Janc <szymon.janc(a)codecoup.pl>
Date: Mon, 26 Feb 2018 15:41:53 +0100
Subject: Bluetooth: Fix missing encryption refresh on Security Request
From: Szymon Janc <szymon.janc(a)codecoup.pl>
commit 64e759f58f128730b97a3c3a26d283c075ad7c86 upstream.
If Security Request is received on connection that is already encrypted
with sufficient security master should perform encryption key refresh
procedure instead of just ignoring Slave Security Request
(Core Spec 5.0 Vol 3 Part H 2.4.6).
> ACL Data RX: Handle 3585 flags 0x02 dlen 6
SMP: Security Request (0x0b) len 1
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28
Handle: 3585
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
Long term key: 44264272a5c426a9e868f034cf0e69f3
> HCI Event: Command Status (0x0f) plen 4
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Encryption Key Refresh Complete (0x30) plen 3
Status: Success (0x00)
Handle: 3585
Signed-off-by: Szymon Janc <szymon.janc(a)codecoup.pl>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bluetooth/smp.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2251,8 +2251,14 @@ static u8 smp_cmd_security_req(struct l2
else
sec_level = authreq_to_seclevel(auth);
- if (smp_sufficient_security(hcon, sec_level, SMP_USE_LTK))
+ if (smp_sufficient_security(hcon, sec_level, SMP_USE_LTK)) {
+ /* If link is already encrypted with sufficient security we
+ * still need refresh encryption as per Core Spec 5.0 Vol 3,
+ * Part H 2.4.6
+ */
+ smp_ltk_encrypt(conn, hcon->sec_level);
return 0;
+ }
if (sec_level > hcon->pending_sec_level)
hcon->pending_sec_level = sec_level;
Patches currently in stable-queue which might be from szymon.janc(a)codecoup.pl are
queue-4.4/bluetooth-fix-missing-encryption-refresh-on-security-request.patch
This is a note to let you know that I've just added the patch titled
xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 19d7df69fdb2636856dc8919de72fc1bf8f79598 Mon Sep 17 00:00:00 2001
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Thu, 1 Feb 2018 08:49:23 +0100
Subject: xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
From: Steffen Klassert <steffen.klassert(a)secunet.com>
commit 19d7df69fdb2636856dc8919de72fc1bf8f79598 upstream.
We don't have a compat layer for xfrm, so userspace and kernel
structures have different sizes in this case. This results in
a broken configuration, so refuse to configure socket policies
when trying to insert from 32 bit userspace as we do it already
with policies inserted via netlink.
Reported-and-tested-by: syzbot+e1a1577ca8bcb47b769a(a)syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_state.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2056,6 +2056,11 @@ int xfrm_user_policy(struct sock *sk, in
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;
+#ifdef CONFIG_COMPAT
+ if (in_compat_syscall())
+ return -EOPNOTSUPP;
+#endif
+
if (!optval && !optlen) {
xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-4.15/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.15/xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
queue-4.15/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
This is a note to let you know that I've just added the patch titled
phy: qcom-ufs: add MODULE_LICENSE tag
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
phy-qcom-ufs-add-module_license-tag.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 59fba0869acae06ff594dd7e9808ed673f53538a Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 17:35:43 +0100
Subject: phy: qcom-ufs: add MODULE_LICENSE tag
From: Arnd Bergmann <arnd(a)arndb.de>
commit 59fba0869acae06ff594dd7e9808ed673f53538a upstream.
While the specific UFS PHY drivers (14nm and 20nm) have a module
license, the common base module does not, leading to a Kbuild
failure:
WARNING: modpost: missing MODULE_LICENSE() in drivers/phy/qualcomm/phy-qcom-ufs.o
FATAL: modpost: GPL-incompatible module phy-qcom-ufs.ko uses GPL-only symbol 'clk_enable'
This adds a module description and license tag to fix the build.
I added both Yaniv and Vivek as authors here, as Yaniv sent the initial
submission, while Vivek did most of the work since.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/phy/qualcomm/phy-qcom-ufs.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/phy/qualcomm/phy-qcom-ufs.c
+++ b/drivers/phy/qualcomm/phy-qcom-ufs.c
@@ -675,3 +675,8 @@ int ufs_qcom_phy_power_off(struct phy *g
return 0;
}
EXPORT_SYMBOL_GPL(ufs_qcom_phy_power_off);
+
+MODULE_AUTHOR("Yaniv Gardi <ygardi(a)codeaurora.org>");
+MODULE_AUTHOR("Vivek Gautam <vivek.gautam(a)codeaurora.org>");
+MODULE_DESCRIPTION("Universal Flash Storage (UFS) QCOM PHY");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/phy-qcom-ufs-add-module_license-tag.patch
This is a note to let you know that I've just added the patch titled
percpu: add __GFP_NORETRY semantics to the percpu balancing path
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
percpu-add-__gfp_noretry-semantics-to-the-percpu-balancing-path.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 47504ee04b9241548ae2c28be7d0b01cff3b7aa6 Mon Sep 17 00:00:00 2001
From: Dennis Zhou <dennisszhou(a)gmail.com>
Date: Fri, 16 Feb 2018 12:07:19 -0600
Subject: percpu: add __GFP_NORETRY semantics to the percpu balancing path
From: Dennis Zhou <dennisszhou(a)gmail.com>
commit 47504ee04b9241548ae2c28be7d0b01cff3b7aa6 upstream.
Percpu memory using the vmalloc area based chunk allocator lazily
populates chunks by first requesting the full virtual address space
required for the chunk and subsequently adding pages as allocations come
through. To ensure atomic allocations can succeed, a workqueue item is
used to maintain a minimum number of empty pages. In certain scenarios,
such as reported in [1], it is possible that physical memory becomes
quite scarce which can result in either a rather long time spent trying
to find free pages or worse, a kernel panic.
This patch adds support for __GFP_NORETRY and __GFP_NOWARN passing them
through to the underlying allocators. This should prevent any
unnecessary panics potentially caused by the workqueue item. The passing
of gfp around is as additional flags rather than a full set of flags.
The next patch will change these to caller passed semantics.
V2:
Added const modifier to gfp flags in the balance path.
Removed an extra whitespace.
[1] https://lkml.org/lkml/2018/2/12/551
Signed-off-by: Dennis Zhou <dennisszhou(a)gmail.com>
Suggested-by: Daniel Borkmann <daniel(a)iogearbox.net>
Reported-by: syzbot+adb03f3f0bb57ce3acda(a)syzkaller.appspotmail.com
Acked-by: Christoph Lameter <cl(a)linux.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/percpu-km.c | 8 ++++----
mm/percpu-vm.c | 18 +++++++++++-------
mm/percpu.c | 45 ++++++++++++++++++++++++++++-----------------
3 files changed, 43 insertions(+), 28 deletions(-)
--- a/mm/percpu-km.c
+++ b/mm/percpu-km.c
@@ -34,7 +34,7 @@
#include <linux/log2.h>
static int pcpu_populate_chunk(struct pcpu_chunk *chunk,
- int page_start, int page_end)
+ int page_start, int page_end, gfp_t gfp)
{
return 0;
}
@@ -45,18 +45,18 @@ static void pcpu_depopulate_chunk(struct
/* nada */
}
-static struct pcpu_chunk *pcpu_create_chunk(void)
+static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp)
{
const int nr_pages = pcpu_group_sizes[0] >> PAGE_SHIFT;
struct pcpu_chunk *chunk;
struct page *pages;
int i;
- chunk = pcpu_alloc_chunk();
+ chunk = pcpu_alloc_chunk(gfp);
if (!chunk)
return NULL;
- pages = alloc_pages(GFP_KERNEL, order_base_2(nr_pages));
+ pages = alloc_pages(gfp | GFP_KERNEL, order_base_2(nr_pages));
if (!pages) {
pcpu_free_chunk(chunk);
return NULL;
--- a/mm/percpu-vm.c
+++ b/mm/percpu-vm.c
@@ -37,7 +37,7 @@ static struct page **pcpu_get_pages(void
lockdep_assert_held(&pcpu_alloc_mutex);
if (!pages)
- pages = pcpu_mem_zalloc(pages_size);
+ pages = pcpu_mem_zalloc(pages_size, 0);
return pages;
}
@@ -73,18 +73,21 @@ static void pcpu_free_pages(struct pcpu_
* @pages: array to put the allocated pages into, indexed by pcpu_page_idx()
* @page_start: page index of the first page to be allocated
* @page_end: page index of the last page to be allocated + 1
+ * @gfp: allocation flags passed to the underlying allocator
*
* Allocate pages [@page_start,@page_end) into @pages for all units.
* The allocation is for @chunk. Percpu core doesn't care about the
* content of @pages and will pass it verbatim to pcpu_map_pages().
*/
static int pcpu_alloc_pages(struct pcpu_chunk *chunk,
- struct page **pages, int page_start, int page_end)
+ struct page **pages, int page_start, int page_end,
+ gfp_t gfp)
{
- const gfp_t gfp = GFP_KERNEL | __GFP_HIGHMEM;
unsigned int cpu, tcpu;
int i;
+ gfp |= GFP_KERNEL | __GFP_HIGHMEM;
+
for_each_possible_cpu(cpu) {
for (i = page_start; i < page_end; i++) {
struct page **pagep = &pages[pcpu_page_idx(cpu, i)];
@@ -262,6 +265,7 @@ static void pcpu_post_map_flush(struct p
* @chunk: chunk of interest
* @page_start: the start page
* @page_end: the end page
+ * @gfp: allocation flags passed to the underlying memory allocator
*
* For each cpu, populate and map pages [@page_start,@page_end) into
* @chunk.
@@ -270,7 +274,7 @@ static void pcpu_post_map_flush(struct p
* pcpu_alloc_mutex, does GFP_KERNEL allocation.
*/
static int pcpu_populate_chunk(struct pcpu_chunk *chunk,
- int page_start, int page_end)
+ int page_start, int page_end, gfp_t gfp)
{
struct page **pages;
@@ -278,7 +282,7 @@ static int pcpu_populate_chunk(struct pc
if (!pages)
return -ENOMEM;
- if (pcpu_alloc_pages(chunk, pages, page_start, page_end))
+ if (pcpu_alloc_pages(chunk, pages, page_start, page_end, gfp))
return -ENOMEM;
if (pcpu_map_pages(chunk, pages, page_start, page_end)) {
@@ -325,12 +329,12 @@ static void pcpu_depopulate_chunk(struct
pcpu_free_pages(chunk, pages, page_start, page_end);
}
-static struct pcpu_chunk *pcpu_create_chunk(void)
+static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp)
{
struct pcpu_chunk *chunk;
struct vm_struct **vms;
- chunk = pcpu_alloc_chunk();
+ chunk = pcpu_alloc_chunk(gfp);
if (!chunk)
return NULL;
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -447,10 +447,12 @@ static void pcpu_next_fit_region(struct
/**
* pcpu_mem_zalloc - allocate memory
* @size: bytes to allocate
+ * @gfp: allocation flags
*
* Allocate @size bytes. If @size is smaller than PAGE_SIZE,
- * kzalloc() is used; otherwise, vzalloc() is used. The returned
- * memory is always zeroed.
+ * kzalloc() is used; otherwise, the equivalent of vzalloc() is used.
+ * This is to facilitate passing through whitelisted flags. The
+ * returned memory is always zeroed.
*
* CONTEXT:
* Does GFP_KERNEL allocation.
@@ -458,15 +460,16 @@ static void pcpu_next_fit_region(struct
* RETURNS:
* Pointer to the allocated area on success, NULL on failure.
*/
-static void *pcpu_mem_zalloc(size_t size)
+static void *pcpu_mem_zalloc(size_t size, gfp_t gfp)
{
if (WARN_ON_ONCE(!slab_is_available()))
return NULL;
if (size <= PAGE_SIZE)
- return kzalloc(size, GFP_KERNEL);
+ return kzalloc(size, gfp | GFP_KERNEL);
else
- return vzalloc(size);
+ return __vmalloc(size, gfp | GFP_KERNEL | __GFP_ZERO,
+ PAGE_KERNEL);
}
/**
@@ -1154,12 +1157,12 @@ static struct pcpu_chunk * __init pcpu_a
return chunk;
}
-static struct pcpu_chunk *pcpu_alloc_chunk(void)
+static struct pcpu_chunk *pcpu_alloc_chunk(gfp_t gfp)
{
struct pcpu_chunk *chunk;
int region_bits;
- chunk = pcpu_mem_zalloc(pcpu_chunk_struct_size);
+ chunk = pcpu_mem_zalloc(pcpu_chunk_struct_size, gfp);
if (!chunk)
return NULL;
@@ -1168,17 +1171,17 @@ static struct pcpu_chunk *pcpu_alloc_chu
region_bits = pcpu_chunk_map_bits(chunk);
chunk->alloc_map = pcpu_mem_zalloc(BITS_TO_LONGS(region_bits) *
- sizeof(chunk->alloc_map[0]));
+ sizeof(chunk->alloc_map[0]), gfp);
if (!chunk->alloc_map)
goto alloc_map_fail;
chunk->bound_map = pcpu_mem_zalloc(BITS_TO_LONGS(region_bits + 1) *
- sizeof(chunk->bound_map[0]));
+ sizeof(chunk->bound_map[0]), gfp);
if (!chunk->bound_map)
goto bound_map_fail;
chunk->md_blocks = pcpu_mem_zalloc(pcpu_chunk_nr_blocks(chunk) *
- sizeof(chunk->md_blocks[0]));
+ sizeof(chunk->md_blocks[0]), gfp);
if (!chunk->md_blocks)
goto md_blocks_fail;
@@ -1277,9 +1280,10 @@ static void pcpu_chunk_depopulated(struc
* pcpu_addr_to_page - translate address to physical address
* pcpu_verify_alloc_info - check alloc_info is acceptable during init
*/
-static int pcpu_populate_chunk(struct pcpu_chunk *chunk, int off, int size);
+static int pcpu_populate_chunk(struct pcpu_chunk *chunk, int off, int size,
+ gfp_t gfp);
static void pcpu_depopulate_chunk(struct pcpu_chunk *chunk, int off, int size);
-static struct pcpu_chunk *pcpu_create_chunk(void);
+static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp);
static void pcpu_destroy_chunk(struct pcpu_chunk *chunk);
static struct page *pcpu_addr_to_page(void *addr);
static int __init pcpu_verify_alloc_info(const struct pcpu_alloc_info *ai);
@@ -1421,7 +1425,7 @@ restart:
}
if (list_empty(&pcpu_slot[pcpu_nr_slots - 1])) {
- chunk = pcpu_create_chunk();
+ chunk = pcpu_create_chunk(0);
if (!chunk) {
err = "failed to allocate new chunk";
goto fail;
@@ -1450,7 +1454,7 @@ area_found:
page_start, page_end) {
WARN_ON(chunk->immutable);
- ret = pcpu_populate_chunk(chunk, rs, re);
+ ret = pcpu_populate_chunk(chunk, rs, re, 0);
spin_lock_irqsave(&pcpu_lock, flags);
if (ret) {
@@ -1561,10 +1565,17 @@ void __percpu *__alloc_reserved_percpu(s
* pcpu_balance_workfn - manage the amount of free chunks and populated pages
* @work: unused
*
- * Reclaim all fully free chunks except for the first one.
+ * Reclaim all fully free chunks except for the first one. This is also
+ * responsible for maintaining the pool of empty populated pages. However,
+ * it is possible that this is called when physical memory is scarce causing
+ * OOM killer to be triggered. We should avoid doing so until an actual
+ * allocation causes the failure as it is possible that requests can be
+ * serviced from already backed regions.
*/
static void pcpu_balance_workfn(struct work_struct *work)
{
+ /* gfp flags passed to underlying allocators */
+ const gfp_t gfp = __GFP_NORETRY | __GFP_NOWARN;
LIST_HEAD(to_free);
struct list_head *free_head = &pcpu_slot[pcpu_nr_slots - 1];
struct pcpu_chunk *chunk, *next;
@@ -1645,7 +1656,7 @@ retry_pop:
chunk->nr_pages) {
int nr = min(re - rs, nr_to_pop);
- ret = pcpu_populate_chunk(chunk, rs, rs + nr);
+ ret = pcpu_populate_chunk(chunk, rs, rs + nr, gfp);
if (!ret) {
nr_to_pop -= nr;
spin_lock_irq(&pcpu_lock);
@@ -1662,7 +1673,7 @@ retry_pop:
if (nr_to_pop) {
/* ran out of chunks to populate, create a new one and retry */
- chunk = pcpu_create_chunk();
+ chunk = pcpu_create_chunk(gfp);
if (chunk) {
spin_lock_irq(&pcpu_lock);
pcpu_chunk_relocate(chunk, -1);
Patches currently in stable-queue which might be from dennisszhou(a)gmail.com are
queue-4.15/percpu-add-__gfp_noretry-semantics-to-the-percpu-balancing-path.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: make allocation less aggressive
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-x_tables-make-allocation-less-aggressive.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0537250fdc6c876ed4cbbe874c739aebef493ee2 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko(a)kernel.org>
Date: Tue, 30 Jan 2018 11:30:11 -0800
Subject: netfilter: x_tables: make allocation less aggressive
From: Michal Hocko <mhocko(a)kernel.org>
commit 0537250fdc6c876ed4cbbe874c739aebef493ee2 upstream.
syzbot has noticed that xt_alloc_table_info can allocate a lot of memory.
This is an admin only interface but an admin in a namespace is sufficient
as well. eacd86ca3b03 ("net/netfilter/x_tables.c: use kvmalloc() in
xt_alloc_table_info()") has changed the opencoded kmalloc->vmalloc
fallback into kvmalloc. It has dropped __GFP_NORETRY on the way because
vmalloc has simply never fully supported __GFP_NORETRY semantic. This is
still the case because e.g. page tables backing the vmalloc area are
hardcoded GFP_KERNEL.
Revert back to __GFP_NORETRY as a poors man defence against excessively
large allocation request here. We will not rule out the OOM killer
completely but __GFP_NORETRY should at least stop the large request in
most cases.
[akpm(a)linux-foundation.org: coding-style fixes]
Fixes: eacd86ca3b03 ("net/netfilter/x_tables.c: use kvmalloc() in xt_alloc_tableLink: http://lkml.kernel.org/r/20180130140104.GE21609@dhcp22.suse.cz
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Acked-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1008,7 +1008,12 @@ struct xt_table_info *xt_alloc_table_inf
if ((size >> PAGE_SHIFT) + 2 > totalram_pages)
return NULL;
- info = kvmalloc(sz, GFP_KERNEL);
+ /* __GFP_NORETRY is not fully supported by kvmalloc but it should
+ * work reasonably well if sz is too large and bail out rather
+ * than shoot all processes down before realizing there is nothing
+ * more to reclaim.
+ */
+ info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
if (!info)
return NULL;
Patches currently in stable-queue which might be from mhocko(a)kernel.org are
queue-4.15/netfilter-x_tables-make-allocation-less-aggressive.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: add and use xt_check_proc_name
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-x_tables-add-and-use-xt_check_proc_name.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b1d0a5d0cba4597c0394997b2d5fced3e3841b4e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Sat, 10 Mar 2018 01:15:45 +0100
Subject: netfilter: x_tables: add and use xt_check_proc_name
From: Florian Westphal <fw(a)strlen.de>
commit b1d0a5d0cba4597c0394997b2d5fced3e3841b4e upstream.
recent and hashlimit both create /proc files, but only check that
name is 0 terminated.
This can trigger WARN() from procfs when name is "" or "/".
Add helper for this and then use it for both.
Cc: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: <syzbot+0502b00edac2a0680b61(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/netfilter/x_tables.h | 2 ++
net/netfilter/x_tables.c | 30 ++++++++++++++++++++++++++++++
net/netfilter/xt_hashlimit.c | 16 ++++++++++------
net/netfilter/xt_recent.c | 6 +++---
4 files changed, 45 insertions(+), 9 deletions(-)
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -285,6 +285,8 @@ unsigned int *xt_alloc_entry_offsets(uns
bool xt_find_jump_offset(const unsigned int *offsets,
unsigned int target, unsigned int size);
+int xt_check_proc_name(const char *name, unsigned int size);
+
int xt_check_match(struct xt_mtchk_param *, unsigned int size, u_int8_t proto,
bool inv_proto);
int xt_check_target(struct xt_tgchk_param *, unsigned int size, u_int8_t proto,
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -423,6 +423,36 @@ textify_hooks(char *buf, size_t size, un
return buf;
}
+/**
+ * xt_check_proc_name - check that name is suitable for /proc file creation
+ *
+ * @name: file name candidate
+ * @size: length of buffer
+ *
+ * some x_tables modules wish to create a file in /proc.
+ * This function makes sure that the name is suitable for this
+ * purpose, it checks that name is NUL terminated and isn't a 'special'
+ * name, like "..".
+ *
+ * returns negative number on error or 0 if name is useable.
+ */
+int xt_check_proc_name(const char *name, unsigned int size)
+{
+ if (name[0] == '\0')
+ return -EINVAL;
+
+ if (strnlen(name, size) == size)
+ return -ENAMETOOLONG;
+
+ if (strcmp(name, ".") == 0 ||
+ strcmp(name, "..") == 0 ||
+ strchr(name, '/'))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(xt_check_proc_name);
+
int xt_check_match(struct xt_mtchk_param *par,
unsigned int size, u_int8_t proto, bool inv_proto)
{
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -915,8 +915,9 @@ static int hashlimit_mt_check_v1(const s
struct hashlimit_cfg3 cfg = {};
int ret;
- if (info->name[sizeof(info->name) - 1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
ret = cfg_copy(&cfg, (void *)&info->cfg, 1);
@@ -933,8 +934,9 @@ static int hashlimit_mt_check_v2(const s
struct hashlimit_cfg3 cfg = {};
int ret;
- if (info->name[sizeof(info->name) - 1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
ret = cfg_copy(&cfg, (void *)&info->cfg, 2);
@@ -948,9 +950,11 @@ static int hashlimit_mt_check_v2(const s
static int hashlimit_mt_check(const struct xt_mtchk_param *par)
{
struct xt_hashlimit_mtinfo3 *info = par->matchinfo;
+ int ret;
- if (info->name[sizeof(info->name) - 1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
return hashlimit_mt_check_common(par, &info->hinfo, &info->cfg,
info->name, 3);
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -361,9 +361,9 @@ static int recent_mt_check(const struct
info->hit_count, XT_RECENT_MAX_NSTAMPS - 1);
return -EINVAL;
}
- if (info->name[0] == '\0' ||
- strnlen(info->name, XT_RECENT_NAME_LEN) == XT_RECENT_NAME_LEN)
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
if (ip_pkt_list_tot && info->hit_count < ip_pkt_list_tot)
nstamp_mask = roundup_pow_of_two(ip_pkt_list_tot) - 1;
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.15/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-4.15/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.15/netfilter-x_tables-make-allocation-less-aggressive.patch
queue-4.15/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
queue-4.15/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
netfilter: bridge: ebt_among: add more missing match size checks
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Fri, 9 Mar 2018 14:27:31 +0100
Subject: netfilter: bridge: ebt_among: add more missing match size checks
From: Florian Westphal <fw(a)strlen.de>
commit c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 upstream.
ebt_among is special, it has a dynamic match size and is exempt
from the central size checks.
commit c4585a2823edf ("bridge: ebt_among: add missing match size checks")
added validation for pool size, but missed fact that the macros
ebt_among_wh_src/dst can already return out-of-bound result because
they do not check value of wh_src/dst_ofs (an offset) vs. the size
of the match that userspace gave to us.
v2:
check that offset has correct alignment.
Paolo Abeni points out that we should also check that src/dst
wormhash arrays do not overlap, and src + length lines up with
start of dst (or vice versa).
v3: compact wormhash_sizes_valid() part
NB: Fixes tag is intentionally wrong, this bug exists from day
one when match was added for 2.6 kernel. Tag is there so stable
maintainers will notice this one too.
Tested with same rules from the earlier patch.
Fixes: c4585a2823edf ("bridge: ebt_among: add missing match size checks")
Reported-by: <syzbot+bdabab6f1983a03fc009(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bridge/netfilter/ebt_among.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
--- a/net/bridge/netfilter/ebt_among.c
+++ b/net/bridge/netfilter/ebt_among.c
@@ -177,6 +177,28 @@ static bool poolsize_invalid(const struc
return w && w->poolsize >= (INT_MAX / sizeof(struct ebt_mac_wormhash_tuple));
}
+static bool wormhash_offset_invalid(int off, unsigned int len)
+{
+ if (off == 0) /* not present */
+ return false;
+
+ if (off < (int)sizeof(struct ebt_among_info) ||
+ off % __alignof__(struct ebt_mac_wormhash))
+ return true;
+
+ off += sizeof(struct ebt_mac_wormhash);
+
+ return off > len;
+}
+
+static bool wormhash_sizes_valid(const struct ebt_mac_wormhash *wh, int a, int b)
+{
+ if (a == 0)
+ a = sizeof(struct ebt_among_info);
+
+ return ebt_mac_wormhash_size(wh) + a == b;
+}
+
static int ebt_among_mt_check(const struct xt_mtchk_param *par)
{
const struct ebt_among_info *info = par->matchinfo;
@@ -189,6 +211,10 @@ static int ebt_among_mt_check(const stru
if (expected_length > em->match_size)
return -EINVAL;
+ if (wormhash_offset_invalid(info->wh_dst_ofs, em->match_size) ||
+ wormhash_offset_invalid(info->wh_src_ofs, em->match_size))
+ return -EINVAL;
+
wh_dst = ebt_among_wh_dst(info);
if (poolsize_invalid(wh_dst))
return -EINVAL;
@@ -201,6 +227,14 @@ static int ebt_among_mt_check(const stru
if (poolsize_invalid(wh_src))
return -EINVAL;
+ if (info->wh_src_ofs < info->wh_dst_ofs) {
+ if (!wormhash_sizes_valid(wh_src, info->wh_src_ofs, info->wh_dst_ofs))
+ return -EINVAL;
+ } else {
+ if (!wormhash_sizes_valid(wh_dst, info->wh_dst_ofs, info->wh_src_ofs))
+ return -EINVAL;
+ }
+
expected_length += ebt_mac_wormhash_size(wh_src);
if (em->match_size != EBT_ALIGN(expected_length)) {
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.15/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-4.15/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.15/netfilter-x_tables-make-allocation-less-aggressive.patch
queue-4.15/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
queue-4.15/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0dcd7876029b58770f769cbb7b484e88e4a305e5 Mon Sep 17 00:00:00 2001
From: Greg Hackmann <ghackmann(a)google.com>
Date: Wed, 7 Mar 2018 14:42:53 -0800
Subject: net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
From: Greg Hackmann <ghackmann(a)google.com>
commit 0dcd7876029b58770f769cbb7b484e88e4a305e5 upstream.
f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
__this_cpu_read() call inside ipcomp_alloc_tfms().
At the time, __this_cpu_read() required the caller to either not care
about races or to handle preemption/interrupt issues. 3.15 tightened
the rules around some per-cpu operations, and now __this_cpu_read()
should never be used in a preemptible context. On 3.15 and later, we
need to use this_cpu_read() instead.
syzkaller reported this leading to the following kernel BUG while
fuzzing sendmsg:
BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101
caller is ipcomp_init_state+0x185/0x990
CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 #154
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Call Trace:
dump_stack+0xb9/0x115
check_preemption_disabled+0x1cb/0x1f0
ipcomp_init_state+0x185/0x990
? __xfrm_init_state+0x876/0xc20
? lock_downgrade+0x5e0/0x5e0
ipcomp4_init_state+0xaa/0x7c0
__xfrm_init_state+0x3eb/0xc20
xfrm_init_state+0x19/0x60
pfkey_add+0x20df/0x36f0
? pfkey_broadcast+0x3dd/0x600
? pfkey_sock_destruct+0x340/0x340
? pfkey_seq_stop+0x80/0x80
? __skb_clone+0x236/0x750
? kmem_cache_alloc+0x1f6/0x260
? pfkey_sock_destruct+0x340/0x340
? pfkey_process+0x62a/0x6f0
pfkey_process+0x62a/0x6f0
? pfkey_send_new_mapping+0x11c0/0x11c0
? mutex_lock_io_nested+0x1390/0x1390
pfkey_sendmsg+0x383/0x750
? dump_sp+0x430/0x430
sock_sendmsg+0xc0/0x100
___sys_sendmsg+0x6c8/0x8b0
? copy_msghdr_from_user+0x3b0/0x3b0
? pagevec_lru_move_fn+0x144/0x1f0
? find_held_lock+0x32/0x1c0
? do_huge_pmd_anonymous_page+0xc43/0x11e0
? lock_downgrade+0x5e0/0x5e0
? get_kernel_page+0xb0/0xb0
? _raw_spin_unlock+0x29/0x40
? do_huge_pmd_anonymous_page+0x400/0x11e0
? __handle_mm_fault+0x553/0x2460
? __fget_light+0x163/0x1f0
? __sys_sendmsg+0xc7/0x170
__sys_sendmsg+0xc7/0x170
? SyS_shutdown+0x1a0/0x1a0
? __do_page_fault+0x5a0/0xca0
? lock_downgrade+0x5e0/0x5e0
SyS_sendmsg+0x27/0x40
? __sys_sendmsg+0x170/0x170
do_syscall_64+0x19f/0x640
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x7f0ee73dfb79
RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79
RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004
RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0
R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440
R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000
Signed-off-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_ipcomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -283,7 +283,7 @@ static struct crypto_comp * __percpu *ip
struct crypto_comp *tfm;
/* This can be any valid CPU ID so we don't need locking. */
- tfm = __this_cpu_read(*pos->tfms);
+ tfm = this_cpu_read(*pos->tfms);
if (!strcmp(crypto_comp_name(tfm), alg_name)) {
pos->users++;
Patches currently in stable-queue which might be from ghackmann(a)google.com are
queue-4.15/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
This is a note to let you know that I've just added the patch titled
l2tp: fix races with ipv4-mapped ipv6 addresses
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
l2tp-fix-races-with-ipv4-mapped-ipv6-addresses.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b954f94023dcc61388c8384f0f14eb8e42c863c5 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Mon, 12 Mar 2018 14:54:24 +0100
Subject: l2tp: fix races with ipv4-mapped ipv6 addresses
From: Paolo Abeni <pabeni(a)redhat.com>
commit b954f94023dcc61388c8384f0f14eb8e42c863c5 upstream.
The l2tp_tunnel_create() function checks for v4mapped ipv6
sockets and cache that flag, so that l2tp core code can
reusing it at xmit time.
If the socket is provided by the userspace, the connection
status of the tunnel sockets can change between the tunnel
creation and the xmit call, so that syzbot is able to
trigger the following splat:
BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:192
[inline]
BUG: KASAN: use-after-free in ip6_xmit+0x1f76/0x2260
net/ipv6/ip6_output.c:264
Read of size 8 at addr ffff8801bd949318 by task syz-executor4/23448
CPU: 0 PID: 23448 Comm: syz-executor4 Not tainted 4.16.0-rc4+ #65
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x23c/0x360 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
ip6_dst_idev include/net/ip6_fib.h:192 [inline]
ip6_xmit+0x1f76/0x2260 net/ipv6/ip6_output.c:264
inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
l2tp_xmit_core net/l2tp/l2tp_core.c:1053 [inline]
l2tp_xmit_skb+0x105f/0x1410 net/l2tp/l2tp_core.c:1148
pppol2tp_sendmsg+0x470/0x670 net/l2tp/l2tp_ppp.c:341
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:640
___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
__sys_sendmsg+0xe5/0x210 net/socket.c:2080
SYSC_sendmsg net/socket.c:2091 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2087
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x453e69
RSP: 002b:00007f819593cc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f819593d6d4 RCX: 0000000000453e69
RDX: 0000000000000081 RSI: 000000002037ffc8 RDI: 0000000000000004
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000004c3 R14: 00000000006f72e8 R15: 0000000000000000
This change addresses the issues:
* explicitly checking for TCP_ESTABLISHED for user space provided sockets
* dropping the v4mapped flag usage - it can become outdated - and
explicitly invoking ipv6_addr_v4mapped() instead
The issue is apparently there since ancient times.
v1 -> v2: (many thanks to Guillaume)
- with csum issue introduced in v1
- replace pr_err with pr_debug
- fix build issue with IPV6 disabled
- move l2tp_sk_is_v4mapped in l2tp_core.c
v2 -> v3:
- don't update inet_daddr for v4mapped address, unneeded
- drop rendundant check at creation time
Reported-and-tested-by: syzbot+92fa328176eb07e4ac1a(a)syzkaller.appspotmail.com
Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 38 ++++++++++++++++++--------------------
net/l2tp/l2tp_core.h | 3 ---
2 files changed, 18 insertions(+), 23 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -111,6 +111,13 @@ struct l2tp_net {
spinlock_t l2tp_session_hlist_lock;
};
+#if IS_ENABLED(CONFIG_IPV6)
+static bool l2tp_sk_is_v6(struct sock *sk)
+{
+ return sk->sk_family == PF_INET6 &&
+ !ipv6_addr_v4mapped(&sk->sk_v6_daddr);
+}
+#endif
static inline struct l2tp_tunnel *l2tp_tunnel(struct sock *sk)
{
@@ -1058,7 +1065,7 @@ static int l2tp_xmit_core(struct l2tp_se
/* Queue the packet to IP for output */
skb->ignore_df = 1;
#if IS_ENABLED(CONFIG_IPV6)
- if (tunnel->sock->sk_family == PF_INET6 && !tunnel->v4mapped)
+ if (l2tp_sk_is_v6(tunnel->sock))
error = inet6_csk_xmit(tunnel->sock, skb, NULL);
else
#endif
@@ -1121,6 +1128,15 @@ int l2tp_xmit_skb(struct l2tp_session *s
goto out_unlock;
}
+ /* The user-space may change the connection status for the user-space
+ * provided socket at run time: we must check it under the socket lock
+ */
+ if (tunnel->fd >= 0 && sk->sk_state != TCP_ESTABLISHED) {
+ kfree_skb(skb);
+ ret = NET_XMIT_DROP;
+ goto out_unlock;
+ }
+
/* Get routing info from the tunnel socket */
skb_dst_drop(skb);
skb_dst_set(skb, dst_clone(__sk_dst_check(sk, 0)));
@@ -1140,7 +1156,7 @@ int l2tp_xmit_skb(struct l2tp_session *s
/* Calculate UDP checksum if configured to do so */
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6 && !tunnel->v4mapped)
+ if (l2tp_sk_is_v6(sk))
udp6_set_csum(udp_get_no_check6_tx(sk),
skb, &inet6_sk(sk)->saddr,
&sk->sk_v6_daddr, udp_len);
@@ -1520,24 +1536,6 @@ int l2tp_tunnel_create(struct net *net,
if (cfg != NULL)
tunnel->debug = cfg->debug;
-#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6) {
- struct ipv6_pinfo *np = inet6_sk(sk);
-
- if (ipv6_addr_v4mapped(&np->saddr) &&
- ipv6_addr_v4mapped(&sk->sk_v6_daddr)) {
- struct inet_sock *inet = inet_sk(sk);
-
- tunnel->v4mapped = true;
- inet->inet_saddr = np->saddr.s6_addr32[3];
- inet->inet_rcv_saddr = sk->sk_v6_rcv_saddr.s6_addr32[3];
- inet->inet_daddr = sk->sk_v6_daddr.s6_addr32[3];
- } else {
- tunnel->v4mapped = false;
- }
- }
-#endif
-
/* Mark socket as an encapsulation socket. See net/ipv4/udp.c */
tunnel->encap = encap;
if (encap == L2TP_ENCAPTYPE_UDP) {
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -193,9 +193,6 @@ struct l2tp_tunnel {
struct sock *sock; /* Parent socket */
int fd; /* Parent fd, if tunnel socket
* was created by userspace */
-#if IS_ENABLED(CONFIG_IPV6)
- bool v4mapped;
-#endif
struct work_struct del_work;
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.15/l2tp-fix-races-with-ipv4-mapped-ipv6-addresses.patch
queue-4.15/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: Fix missing encryption refresh on Security Request
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-fix-missing-encryption-refresh-on-security-request.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 64e759f58f128730b97a3c3a26d283c075ad7c86 Mon Sep 17 00:00:00 2001
From: Szymon Janc <szymon.janc(a)codecoup.pl>
Date: Mon, 26 Feb 2018 15:41:53 +0100
Subject: Bluetooth: Fix missing encryption refresh on Security Request
From: Szymon Janc <szymon.janc(a)codecoup.pl>
commit 64e759f58f128730b97a3c3a26d283c075ad7c86 upstream.
If Security Request is received on connection that is already encrypted
with sufficient security master should perform encryption key refresh
procedure instead of just ignoring Slave Security Request
(Core Spec 5.0 Vol 3 Part H 2.4.6).
> ACL Data RX: Handle 3585 flags 0x02 dlen 6
SMP: Security Request (0x0b) len 1
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28
Handle: 3585
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
Long term key: 44264272a5c426a9e868f034cf0e69f3
> HCI Event: Command Status (0x0f) plen 4
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Encryption Key Refresh Complete (0x30) plen 3
Status: Success (0x00)
Handle: 3585
Signed-off-by: Szymon Janc <szymon.janc(a)codecoup.pl>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bluetooth/smp.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2296,8 +2296,14 @@ static u8 smp_cmd_security_req(struct l2
else
sec_level = authreq_to_seclevel(auth);
- if (smp_sufficient_security(hcon, sec_level, SMP_USE_LTK))
+ if (smp_sufficient_security(hcon, sec_level, SMP_USE_LTK)) {
+ /* If link is already encrypted with sufficient security we
+ * still need refresh encryption as per Core Spec 5.0 Vol 3,
+ * Part H 2.4.6
+ */
+ smp_ltk_encrypt(conn, hcon->sec_level);
return 0;
+ }
if (sec_level > hcon->pending_sec_level)
hcon->pending_sec_level = sec_level;
Patches currently in stable-queue which might be from szymon.janc(a)codecoup.pl are
queue-4.15/bluetooth-fix-missing-encryption-refresh-on-security-request.patch
This is a note to let you know that I've just added the patch titled
xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 19d7df69fdb2636856dc8919de72fc1bf8f79598 Mon Sep 17 00:00:00 2001
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Thu, 1 Feb 2018 08:49:23 +0100
Subject: xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
From: Steffen Klassert <steffen.klassert(a)secunet.com>
commit 19d7df69fdb2636856dc8919de72fc1bf8f79598 upstream.
We don't have a compat layer for xfrm, so userspace and kernel
structures have different sizes in this case. This results in
a broken configuration, so refuse to configure socket policies
when trying to insert from 32 bit userspace as we do it already
with policies inserted via netlink.
Reported-and-tested-by: syzbot+e1a1577ca8bcb47b769a(a)syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_state.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2050,6 +2050,11 @@ int xfrm_user_policy(struct sock *sk, in
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;
+#ifdef CONFIG_COMPAT
+ if (in_compat_syscall())
+ return -EOPNOTSUPP;
+#endif
+
if (!optval && !optlen) {
xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-4.14/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.14/xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
queue-4.14/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
This is a note to let you know that I've just added the patch titled
phy: qcom-ufs: add MODULE_LICENSE tag
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
phy-qcom-ufs-add-module_license-tag.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 59fba0869acae06ff594dd7e9808ed673f53538a Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 17:35:43 +0100
Subject: phy: qcom-ufs: add MODULE_LICENSE tag
From: Arnd Bergmann <arnd(a)arndb.de>
commit 59fba0869acae06ff594dd7e9808ed673f53538a upstream.
While the specific UFS PHY drivers (14nm and 20nm) have a module
license, the common base module does not, leading to a Kbuild
failure:
WARNING: modpost: missing MODULE_LICENSE() in drivers/phy/qualcomm/phy-qcom-ufs.o
FATAL: modpost: GPL-incompatible module phy-qcom-ufs.ko uses GPL-only symbol 'clk_enable'
This adds a module description and license tag to fix the build.
I added both Yaniv and Vivek as authors here, as Yaniv sent the initial
submission, while Vivek did most of the work since.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/phy/qualcomm/phy-qcom-ufs.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/phy/qualcomm/phy-qcom-ufs.c
+++ b/drivers/phy/qualcomm/phy-qcom-ufs.c
@@ -689,3 +689,8 @@ int ufs_qcom_phy_power_off(struct phy *g
return 0;
}
EXPORT_SYMBOL_GPL(ufs_qcom_phy_power_off);
+
+MODULE_AUTHOR("Yaniv Gardi <ygardi(a)codeaurora.org>");
+MODULE_AUTHOR("Vivek Gautam <vivek.gautam(a)codeaurora.org>");
+MODULE_DESCRIPTION("Universal Flash Storage (UFS) QCOM PHY");
+MODULE_LICENSE("GPL v2");
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/phy-qcom-ufs-add-module_license-tag.patch
This is a note to let you know that I've just added the patch titled
percpu: add __GFP_NORETRY semantics to the percpu balancing path
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
percpu-add-__gfp_noretry-semantics-to-the-percpu-balancing-path.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 47504ee04b9241548ae2c28be7d0b01cff3b7aa6 Mon Sep 17 00:00:00 2001
From: Dennis Zhou <dennisszhou(a)gmail.com>
Date: Fri, 16 Feb 2018 12:07:19 -0600
Subject: percpu: add __GFP_NORETRY semantics to the percpu balancing path
From: Dennis Zhou <dennisszhou(a)gmail.com>
commit 47504ee04b9241548ae2c28be7d0b01cff3b7aa6 upstream.
Percpu memory using the vmalloc area based chunk allocator lazily
populates chunks by first requesting the full virtual address space
required for the chunk and subsequently adding pages as allocations come
through. To ensure atomic allocations can succeed, a workqueue item is
used to maintain a minimum number of empty pages. In certain scenarios,
such as reported in [1], it is possible that physical memory becomes
quite scarce which can result in either a rather long time spent trying
to find free pages or worse, a kernel panic.
This patch adds support for __GFP_NORETRY and __GFP_NOWARN passing them
through to the underlying allocators. This should prevent any
unnecessary panics potentially caused by the workqueue item. The passing
of gfp around is as additional flags rather than a full set of flags.
The next patch will change these to caller passed semantics.
V2:
Added const modifier to gfp flags in the balance path.
Removed an extra whitespace.
[1] https://lkml.org/lkml/2018/2/12/551
Signed-off-by: Dennis Zhou <dennisszhou(a)gmail.com>
Suggested-by: Daniel Borkmann <daniel(a)iogearbox.net>
Reported-by: syzbot+adb03f3f0bb57ce3acda(a)syzkaller.appspotmail.com
Acked-by: Christoph Lameter <cl(a)linux.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/percpu-km.c | 8 ++++----
mm/percpu-vm.c | 18 +++++++++++-------
mm/percpu.c | 45 ++++++++++++++++++++++++++++-----------------
3 files changed, 43 insertions(+), 28 deletions(-)
--- a/mm/percpu-km.c
+++ b/mm/percpu-km.c
@@ -34,7 +34,7 @@
#include <linux/log2.h>
static int pcpu_populate_chunk(struct pcpu_chunk *chunk,
- int page_start, int page_end)
+ int page_start, int page_end, gfp_t gfp)
{
return 0;
}
@@ -45,18 +45,18 @@ static void pcpu_depopulate_chunk(struct
/* nada */
}
-static struct pcpu_chunk *pcpu_create_chunk(void)
+static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp)
{
const int nr_pages = pcpu_group_sizes[0] >> PAGE_SHIFT;
struct pcpu_chunk *chunk;
struct page *pages;
int i;
- chunk = pcpu_alloc_chunk();
+ chunk = pcpu_alloc_chunk(gfp);
if (!chunk)
return NULL;
- pages = alloc_pages(GFP_KERNEL, order_base_2(nr_pages));
+ pages = alloc_pages(gfp | GFP_KERNEL, order_base_2(nr_pages));
if (!pages) {
pcpu_free_chunk(chunk);
return NULL;
--- a/mm/percpu-vm.c
+++ b/mm/percpu-vm.c
@@ -37,7 +37,7 @@ static struct page **pcpu_get_pages(void
lockdep_assert_held(&pcpu_alloc_mutex);
if (!pages)
- pages = pcpu_mem_zalloc(pages_size);
+ pages = pcpu_mem_zalloc(pages_size, 0);
return pages;
}
@@ -73,18 +73,21 @@ static void pcpu_free_pages(struct pcpu_
* @pages: array to put the allocated pages into, indexed by pcpu_page_idx()
* @page_start: page index of the first page to be allocated
* @page_end: page index of the last page to be allocated + 1
+ * @gfp: allocation flags passed to the underlying allocator
*
* Allocate pages [@page_start,@page_end) into @pages for all units.
* The allocation is for @chunk. Percpu core doesn't care about the
* content of @pages and will pass it verbatim to pcpu_map_pages().
*/
static int pcpu_alloc_pages(struct pcpu_chunk *chunk,
- struct page **pages, int page_start, int page_end)
+ struct page **pages, int page_start, int page_end,
+ gfp_t gfp)
{
- const gfp_t gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_COLD;
unsigned int cpu, tcpu;
int i;
+ gfp |= GFP_KERNEL | __GFP_HIGHMEM | __GFP_COLD;
+
for_each_possible_cpu(cpu) {
for (i = page_start; i < page_end; i++) {
struct page **pagep = &pages[pcpu_page_idx(cpu, i)];
@@ -262,6 +265,7 @@ static void pcpu_post_map_flush(struct p
* @chunk: chunk of interest
* @page_start: the start page
* @page_end: the end page
+ * @gfp: allocation flags passed to the underlying memory allocator
*
* For each cpu, populate and map pages [@page_start,@page_end) into
* @chunk.
@@ -270,7 +274,7 @@ static void pcpu_post_map_flush(struct p
* pcpu_alloc_mutex, does GFP_KERNEL allocation.
*/
static int pcpu_populate_chunk(struct pcpu_chunk *chunk,
- int page_start, int page_end)
+ int page_start, int page_end, gfp_t gfp)
{
struct page **pages;
@@ -278,7 +282,7 @@ static int pcpu_populate_chunk(struct pc
if (!pages)
return -ENOMEM;
- if (pcpu_alloc_pages(chunk, pages, page_start, page_end))
+ if (pcpu_alloc_pages(chunk, pages, page_start, page_end, gfp))
return -ENOMEM;
if (pcpu_map_pages(chunk, pages, page_start, page_end)) {
@@ -325,12 +329,12 @@ static void pcpu_depopulate_chunk(struct
pcpu_free_pages(chunk, pages, page_start, page_end);
}
-static struct pcpu_chunk *pcpu_create_chunk(void)
+static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp)
{
struct pcpu_chunk *chunk;
struct vm_struct **vms;
- chunk = pcpu_alloc_chunk();
+ chunk = pcpu_alloc_chunk(gfp);
if (!chunk)
return NULL;
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -447,10 +447,12 @@ static void pcpu_next_fit_region(struct
/**
* pcpu_mem_zalloc - allocate memory
* @size: bytes to allocate
+ * @gfp: allocation flags
*
* Allocate @size bytes. If @size is smaller than PAGE_SIZE,
- * kzalloc() is used; otherwise, vzalloc() is used. The returned
- * memory is always zeroed.
+ * kzalloc() is used; otherwise, the equivalent of vzalloc() is used.
+ * This is to facilitate passing through whitelisted flags. The
+ * returned memory is always zeroed.
*
* CONTEXT:
* Does GFP_KERNEL allocation.
@@ -458,15 +460,16 @@ static void pcpu_next_fit_region(struct
* RETURNS:
* Pointer to the allocated area on success, NULL on failure.
*/
-static void *pcpu_mem_zalloc(size_t size)
+static void *pcpu_mem_zalloc(size_t size, gfp_t gfp)
{
if (WARN_ON_ONCE(!slab_is_available()))
return NULL;
if (size <= PAGE_SIZE)
- return kzalloc(size, GFP_KERNEL);
+ return kzalloc(size, gfp | GFP_KERNEL);
else
- return vzalloc(size);
+ return __vmalloc(size, gfp | GFP_KERNEL | __GFP_ZERO,
+ PAGE_KERNEL);
}
/**
@@ -1154,12 +1157,12 @@ static struct pcpu_chunk * __init pcpu_a
return chunk;
}
-static struct pcpu_chunk *pcpu_alloc_chunk(void)
+static struct pcpu_chunk *pcpu_alloc_chunk(gfp_t gfp)
{
struct pcpu_chunk *chunk;
int region_bits;
- chunk = pcpu_mem_zalloc(pcpu_chunk_struct_size);
+ chunk = pcpu_mem_zalloc(pcpu_chunk_struct_size, gfp);
if (!chunk)
return NULL;
@@ -1168,17 +1171,17 @@ static struct pcpu_chunk *pcpu_alloc_chu
region_bits = pcpu_chunk_map_bits(chunk);
chunk->alloc_map = pcpu_mem_zalloc(BITS_TO_LONGS(region_bits) *
- sizeof(chunk->alloc_map[0]));
+ sizeof(chunk->alloc_map[0]), gfp);
if (!chunk->alloc_map)
goto alloc_map_fail;
chunk->bound_map = pcpu_mem_zalloc(BITS_TO_LONGS(region_bits + 1) *
- sizeof(chunk->bound_map[0]));
+ sizeof(chunk->bound_map[0]), gfp);
if (!chunk->bound_map)
goto bound_map_fail;
chunk->md_blocks = pcpu_mem_zalloc(pcpu_chunk_nr_blocks(chunk) *
- sizeof(chunk->md_blocks[0]));
+ sizeof(chunk->md_blocks[0]), gfp);
if (!chunk->md_blocks)
goto md_blocks_fail;
@@ -1277,9 +1280,10 @@ static void pcpu_chunk_depopulated(struc
* pcpu_addr_to_page - translate address to physical address
* pcpu_verify_alloc_info - check alloc_info is acceptable during init
*/
-static int pcpu_populate_chunk(struct pcpu_chunk *chunk, int off, int size);
+static int pcpu_populate_chunk(struct pcpu_chunk *chunk, int off, int size,
+ gfp_t gfp);
static void pcpu_depopulate_chunk(struct pcpu_chunk *chunk, int off, int size);
-static struct pcpu_chunk *pcpu_create_chunk(void);
+static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp);
static void pcpu_destroy_chunk(struct pcpu_chunk *chunk);
static struct page *pcpu_addr_to_page(void *addr);
static int __init pcpu_verify_alloc_info(const struct pcpu_alloc_info *ai);
@@ -1421,7 +1425,7 @@ restart:
}
if (list_empty(&pcpu_slot[pcpu_nr_slots - 1])) {
- chunk = pcpu_create_chunk();
+ chunk = pcpu_create_chunk(0);
if (!chunk) {
err = "failed to allocate new chunk";
goto fail;
@@ -1450,7 +1454,7 @@ area_found:
page_start, page_end) {
WARN_ON(chunk->immutable);
- ret = pcpu_populate_chunk(chunk, rs, re);
+ ret = pcpu_populate_chunk(chunk, rs, re, 0);
spin_lock_irqsave(&pcpu_lock, flags);
if (ret) {
@@ -1561,10 +1565,17 @@ void __percpu *__alloc_reserved_percpu(s
* pcpu_balance_workfn - manage the amount of free chunks and populated pages
* @work: unused
*
- * Reclaim all fully free chunks except for the first one.
+ * Reclaim all fully free chunks except for the first one. This is also
+ * responsible for maintaining the pool of empty populated pages. However,
+ * it is possible that this is called when physical memory is scarce causing
+ * OOM killer to be triggered. We should avoid doing so until an actual
+ * allocation causes the failure as it is possible that requests can be
+ * serviced from already backed regions.
*/
static void pcpu_balance_workfn(struct work_struct *work)
{
+ /* gfp flags passed to underlying allocators */
+ const gfp_t gfp = __GFP_NORETRY | __GFP_NOWARN;
LIST_HEAD(to_free);
struct list_head *free_head = &pcpu_slot[pcpu_nr_slots - 1];
struct pcpu_chunk *chunk, *next;
@@ -1645,7 +1656,7 @@ retry_pop:
chunk->nr_pages) {
int nr = min(re - rs, nr_to_pop);
- ret = pcpu_populate_chunk(chunk, rs, rs + nr);
+ ret = pcpu_populate_chunk(chunk, rs, rs + nr, gfp);
if (!ret) {
nr_to_pop -= nr;
spin_lock_irq(&pcpu_lock);
@@ -1662,7 +1673,7 @@ retry_pop:
if (nr_to_pop) {
/* ran out of chunks to populate, create a new one and retry */
- chunk = pcpu_create_chunk();
+ chunk = pcpu_create_chunk(gfp);
if (chunk) {
spin_lock_irq(&pcpu_lock);
pcpu_chunk_relocate(chunk, -1);
Patches currently in stable-queue which might be from dennisszhou(a)gmail.com are
queue-4.14/percpu-add-__gfp_noretry-semantics-to-the-percpu-balancing-path.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: make allocation less aggressive
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-x_tables-make-allocation-less-aggressive.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0537250fdc6c876ed4cbbe874c739aebef493ee2 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko(a)kernel.org>
Date: Tue, 30 Jan 2018 11:30:11 -0800
Subject: netfilter: x_tables: make allocation less aggressive
From: Michal Hocko <mhocko(a)kernel.org>
commit 0537250fdc6c876ed4cbbe874c739aebef493ee2 upstream.
syzbot has noticed that xt_alloc_table_info can allocate a lot of memory.
This is an admin only interface but an admin in a namespace is sufficient
as well. eacd86ca3b03 ("net/netfilter/x_tables.c: use kvmalloc() in
xt_alloc_table_info()") has changed the opencoded kmalloc->vmalloc
fallback into kvmalloc. It has dropped __GFP_NORETRY on the way because
vmalloc has simply never fully supported __GFP_NORETRY semantic. This is
still the case because e.g. page tables backing the vmalloc area are
hardcoded GFP_KERNEL.
Revert back to __GFP_NORETRY as a poors man defence against excessively
large allocation request here. We will not rule out the OOM killer
completely but __GFP_NORETRY should at least stop the large request in
most cases.
[akpm(a)linux-foundation.org: coding-style fixes]
Fixes: eacd86ca3b03 ("net/netfilter/x_tables.c: use kvmalloc() in xt_alloc_tableLink: http://lkml.kernel.org/r/20180130140104.GE21609@dhcp22.suse.cz
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Acked-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1008,7 +1008,12 @@ struct xt_table_info *xt_alloc_table_inf
if ((size >> PAGE_SHIFT) + 2 > totalram_pages)
return NULL;
- info = kvmalloc(sz, GFP_KERNEL);
+ /* __GFP_NORETRY is not fully supported by kvmalloc but it should
+ * work reasonably well if sz is too large and bail out rather
+ * than shoot all processes down before realizing there is nothing
+ * more to reclaim.
+ */
+ info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
if (!info)
return NULL;
Patches currently in stable-queue which might be from mhocko(a)kernel.org are
queue-4.14/netfilter-x_tables-make-allocation-less-aggressive.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: add and use xt_check_proc_name
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-x_tables-add-and-use-xt_check_proc_name.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b1d0a5d0cba4597c0394997b2d5fced3e3841b4e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Sat, 10 Mar 2018 01:15:45 +0100
Subject: netfilter: x_tables: add and use xt_check_proc_name
From: Florian Westphal <fw(a)strlen.de>
commit b1d0a5d0cba4597c0394997b2d5fced3e3841b4e upstream.
recent and hashlimit both create /proc files, but only check that
name is 0 terminated.
This can trigger WARN() from procfs when name is "" or "/".
Add helper for this and then use it for both.
Cc: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: <syzbot+0502b00edac2a0680b61(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/netfilter/x_tables.h | 2 ++
net/netfilter/x_tables.c | 30 ++++++++++++++++++++++++++++++
net/netfilter/xt_hashlimit.c | 16 ++++++++++------
net/netfilter/xt_recent.c | 6 +++---
4 files changed, 45 insertions(+), 9 deletions(-)
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -285,6 +285,8 @@ unsigned int *xt_alloc_entry_offsets(uns
bool xt_find_jump_offset(const unsigned int *offsets,
unsigned int target, unsigned int size);
+int xt_check_proc_name(const char *name, unsigned int size);
+
int xt_check_match(struct xt_mtchk_param *, unsigned int size, u_int8_t proto,
bool inv_proto);
int xt_check_target(struct xt_tgchk_param *, unsigned int size, u_int8_t proto,
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -423,6 +423,36 @@ textify_hooks(char *buf, size_t size, un
return buf;
}
+/**
+ * xt_check_proc_name - check that name is suitable for /proc file creation
+ *
+ * @name: file name candidate
+ * @size: length of buffer
+ *
+ * some x_tables modules wish to create a file in /proc.
+ * This function makes sure that the name is suitable for this
+ * purpose, it checks that name is NUL terminated and isn't a 'special'
+ * name, like "..".
+ *
+ * returns negative number on error or 0 if name is useable.
+ */
+int xt_check_proc_name(const char *name, unsigned int size)
+{
+ if (name[0] == '\0')
+ return -EINVAL;
+
+ if (strnlen(name, size) == size)
+ return -ENAMETOOLONG;
+
+ if (strcmp(name, ".") == 0 ||
+ strcmp(name, "..") == 0 ||
+ strchr(name, '/'))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(xt_check_proc_name);
+
int xt_check_match(struct xt_mtchk_param *par,
unsigned int size, u_int8_t proto, bool inv_proto)
{
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -915,8 +915,9 @@ static int hashlimit_mt_check_v1(const s
struct hashlimit_cfg3 cfg = {};
int ret;
- if (info->name[sizeof(info->name) - 1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
ret = cfg_copy(&cfg, (void *)&info->cfg, 1);
@@ -933,8 +934,9 @@ static int hashlimit_mt_check_v2(const s
struct hashlimit_cfg3 cfg = {};
int ret;
- if (info->name[sizeof(info->name) - 1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
ret = cfg_copy(&cfg, (void *)&info->cfg, 2);
@@ -948,9 +950,11 @@ static int hashlimit_mt_check_v2(const s
static int hashlimit_mt_check(const struct xt_mtchk_param *par)
{
struct xt_hashlimit_mtinfo3 *info = par->matchinfo;
+ int ret;
- if (info->name[sizeof(info->name) - 1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
return hashlimit_mt_check_common(par, &info->hinfo, &info->cfg,
info->name, 3);
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -361,9 +361,9 @@ static int recent_mt_check(const struct
info->hit_count, XT_RECENT_MAX_NSTAMPS - 1);
return -EINVAL;
}
- if (info->name[0] == '\0' ||
- strnlen(info->name, XT_RECENT_NAME_LEN) == XT_RECENT_NAME_LEN)
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
if (ip_pkt_list_tot && info->hit_count < ip_pkt_list_tot)
nstamp_mask = roundup_pow_of_two(ip_pkt_list_tot) - 1;
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.14/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-4.14/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.14/netfilter-x_tables-make-allocation-less-aggressive.patch
queue-4.14/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
queue-4.14/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
netfilter: bridge: ebt_among: add more missing match size checks
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Fri, 9 Mar 2018 14:27:31 +0100
Subject: netfilter: bridge: ebt_among: add more missing match size checks
From: Florian Westphal <fw(a)strlen.de>
commit c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 upstream.
ebt_among is special, it has a dynamic match size and is exempt
from the central size checks.
commit c4585a2823edf ("bridge: ebt_among: add missing match size checks")
added validation for pool size, but missed fact that the macros
ebt_among_wh_src/dst can already return out-of-bound result because
they do not check value of wh_src/dst_ofs (an offset) vs. the size
of the match that userspace gave to us.
v2:
check that offset has correct alignment.
Paolo Abeni points out that we should also check that src/dst
wormhash arrays do not overlap, and src + length lines up with
start of dst (or vice versa).
v3: compact wormhash_sizes_valid() part
NB: Fixes tag is intentionally wrong, this bug exists from day
one when match was added for 2.6 kernel. Tag is there so stable
maintainers will notice this one too.
Tested with same rules from the earlier patch.
Fixes: c4585a2823edf ("bridge: ebt_among: add missing match size checks")
Reported-by: <syzbot+bdabab6f1983a03fc009(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bridge/netfilter/ebt_among.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
--- a/net/bridge/netfilter/ebt_among.c
+++ b/net/bridge/netfilter/ebt_among.c
@@ -177,6 +177,28 @@ static bool poolsize_invalid(const struc
return w && w->poolsize >= (INT_MAX / sizeof(struct ebt_mac_wormhash_tuple));
}
+static bool wormhash_offset_invalid(int off, unsigned int len)
+{
+ if (off == 0) /* not present */
+ return false;
+
+ if (off < (int)sizeof(struct ebt_among_info) ||
+ off % __alignof__(struct ebt_mac_wormhash))
+ return true;
+
+ off += sizeof(struct ebt_mac_wormhash);
+
+ return off > len;
+}
+
+static bool wormhash_sizes_valid(const struct ebt_mac_wormhash *wh, int a, int b)
+{
+ if (a == 0)
+ a = sizeof(struct ebt_among_info);
+
+ return ebt_mac_wormhash_size(wh) + a == b;
+}
+
static int ebt_among_mt_check(const struct xt_mtchk_param *par)
{
const struct ebt_among_info *info = par->matchinfo;
@@ -189,6 +211,10 @@ static int ebt_among_mt_check(const stru
if (expected_length > em->match_size)
return -EINVAL;
+ if (wormhash_offset_invalid(info->wh_dst_ofs, em->match_size) ||
+ wormhash_offset_invalid(info->wh_src_ofs, em->match_size))
+ return -EINVAL;
+
wh_dst = ebt_among_wh_dst(info);
if (poolsize_invalid(wh_dst))
return -EINVAL;
@@ -201,6 +227,14 @@ static int ebt_among_mt_check(const stru
if (poolsize_invalid(wh_src))
return -EINVAL;
+ if (info->wh_src_ofs < info->wh_dst_ofs) {
+ if (!wormhash_sizes_valid(wh_src, info->wh_src_ofs, info->wh_dst_ofs))
+ return -EINVAL;
+ } else {
+ if (!wormhash_sizes_valid(wh_dst, info->wh_dst_ofs, info->wh_src_ofs))
+ return -EINVAL;
+ }
+
expected_length += ebt_mac_wormhash_size(wh_src);
if (em->match_size != EBT_ALIGN(expected_length)) {
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.14/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-4.14/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-4.14/netfilter-x_tables-make-allocation-less-aggressive.patch
queue-4.14/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
queue-4.14/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0dcd7876029b58770f769cbb7b484e88e4a305e5 Mon Sep 17 00:00:00 2001
From: Greg Hackmann <ghackmann(a)google.com>
Date: Wed, 7 Mar 2018 14:42:53 -0800
Subject: net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
From: Greg Hackmann <ghackmann(a)google.com>
commit 0dcd7876029b58770f769cbb7b484e88e4a305e5 upstream.
f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
__this_cpu_read() call inside ipcomp_alloc_tfms().
At the time, __this_cpu_read() required the caller to either not care
about races or to handle preemption/interrupt issues. 3.15 tightened
the rules around some per-cpu operations, and now __this_cpu_read()
should never be used in a preemptible context. On 3.15 and later, we
need to use this_cpu_read() instead.
syzkaller reported this leading to the following kernel BUG while
fuzzing sendmsg:
BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101
caller is ipcomp_init_state+0x185/0x990
CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 #154
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Call Trace:
dump_stack+0xb9/0x115
check_preemption_disabled+0x1cb/0x1f0
ipcomp_init_state+0x185/0x990
? __xfrm_init_state+0x876/0xc20
? lock_downgrade+0x5e0/0x5e0
ipcomp4_init_state+0xaa/0x7c0
__xfrm_init_state+0x3eb/0xc20
xfrm_init_state+0x19/0x60
pfkey_add+0x20df/0x36f0
? pfkey_broadcast+0x3dd/0x600
? pfkey_sock_destruct+0x340/0x340
? pfkey_seq_stop+0x80/0x80
? __skb_clone+0x236/0x750
? kmem_cache_alloc+0x1f6/0x260
? pfkey_sock_destruct+0x340/0x340
? pfkey_process+0x62a/0x6f0
pfkey_process+0x62a/0x6f0
? pfkey_send_new_mapping+0x11c0/0x11c0
? mutex_lock_io_nested+0x1390/0x1390
pfkey_sendmsg+0x383/0x750
? dump_sp+0x430/0x430
sock_sendmsg+0xc0/0x100
___sys_sendmsg+0x6c8/0x8b0
? copy_msghdr_from_user+0x3b0/0x3b0
? pagevec_lru_move_fn+0x144/0x1f0
? find_held_lock+0x32/0x1c0
? do_huge_pmd_anonymous_page+0xc43/0x11e0
? lock_downgrade+0x5e0/0x5e0
? get_kernel_page+0xb0/0xb0
? _raw_spin_unlock+0x29/0x40
? do_huge_pmd_anonymous_page+0x400/0x11e0
? __handle_mm_fault+0x553/0x2460
? __fget_light+0x163/0x1f0
? __sys_sendmsg+0xc7/0x170
__sys_sendmsg+0xc7/0x170
? SyS_shutdown+0x1a0/0x1a0
? __do_page_fault+0x5a0/0xca0
? lock_downgrade+0x5e0/0x5e0
SyS_sendmsg+0x27/0x40
? __sys_sendmsg+0x170/0x170
do_syscall_64+0x19f/0x640
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x7f0ee73dfb79
RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79
RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004
RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0
R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440
R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000
Signed-off-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_ipcomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -283,7 +283,7 @@ static struct crypto_comp * __percpu *ip
struct crypto_comp *tfm;
/* This can be any valid CPU ID so we don't need locking. */
- tfm = __this_cpu_read(*pos->tfms);
+ tfm = this_cpu_read(*pos->tfms);
if (!strcmp(crypto_comp_name(tfm), alg_name)) {
pos->users++;
Patches currently in stable-queue which might be from ghackmann(a)google.com are
queue-4.14/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
This is a note to let you know that I've just added the patch titled
l2tp: fix races with ipv4-mapped ipv6 addresses
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
l2tp-fix-races-with-ipv4-mapped-ipv6-addresses.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b954f94023dcc61388c8384f0f14eb8e42c863c5 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Mon, 12 Mar 2018 14:54:24 +0100
Subject: l2tp: fix races with ipv4-mapped ipv6 addresses
From: Paolo Abeni <pabeni(a)redhat.com>
commit b954f94023dcc61388c8384f0f14eb8e42c863c5 upstream.
The l2tp_tunnel_create() function checks for v4mapped ipv6
sockets and cache that flag, so that l2tp core code can
reusing it at xmit time.
If the socket is provided by the userspace, the connection
status of the tunnel sockets can change between the tunnel
creation and the xmit call, so that syzbot is able to
trigger the following splat:
BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:192
[inline]
BUG: KASAN: use-after-free in ip6_xmit+0x1f76/0x2260
net/ipv6/ip6_output.c:264
Read of size 8 at addr ffff8801bd949318 by task syz-executor4/23448
CPU: 0 PID: 23448 Comm: syz-executor4 Not tainted 4.16.0-rc4+ #65
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x23c/0x360 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
ip6_dst_idev include/net/ip6_fib.h:192 [inline]
ip6_xmit+0x1f76/0x2260 net/ipv6/ip6_output.c:264
inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
l2tp_xmit_core net/l2tp/l2tp_core.c:1053 [inline]
l2tp_xmit_skb+0x105f/0x1410 net/l2tp/l2tp_core.c:1148
pppol2tp_sendmsg+0x470/0x670 net/l2tp/l2tp_ppp.c:341
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:640
___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
__sys_sendmsg+0xe5/0x210 net/socket.c:2080
SYSC_sendmsg net/socket.c:2091 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2087
do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x453e69
RSP: 002b:00007f819593cc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f819593d6d4 RCX: 0000000000453e69
RDX: 0000000000000081 RSI: 000000002037ffc8 RDI: 0000000000000004
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000004c3 R14: 00000000006f72e8 R15: 0000000000000000
This change addresses the issues:
* explicitly checking for TCP_ESTABLISHED for user space provided sockets
* dropping the v4mapped flag usage - it can become outdated - and
explicitly invoking ipv6_addr_v4mapped() instead
The issue is apparently there since ancient times.
v1 -> v2: (many thanks to Guillaume)
- with csum issue introduced in v1
- replace pr_err with pr_debug
- fix build issue with IPV6 disabled
- move l2tp_sk_is_v4mapped in l2tp_core.c
v2 -> v3:
- don't update inet_daddr for v4mapped address, unneeded
- drop rendundant check at creation time
Reported-and-tested-by: syzbot+92fa328176eb07e4ac1a(a)syzkaller.appspotmail.com
Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 38 ++++++++++++++++++--------------------
net/l2tp/l2tp_core.h | 3 ---
2 files changed, 18 insertions(+), 23 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -113,6 +113,13 @@ struct l2tp_net {
spinlock_t l2tp_session_hlist_lock;
};
+#if IS_ENABLED(CONFIG_IPV6)
+static bool l2tp_sk_is_v6(struct sock *sk)
+{
+ return sk->sk_family == PF_INET6 &&
+ !ipv6_addr_v4mapped(&sk->sk_v6_daddr);
+}
+#endif
static inline struct l2tp_tunnel *l2tp_tunnel(struct sock *sk)
{
@@ -1130,7 +1137,7 @@ static int l2tp_xmit_core(struct l2tp_se
/* Queue the packet to IP for output */
skb->ignore_df = 1;
#if IS_ENABLED(CONFIG_IPV6)
- if (tunnel->sock->sk_family == PF_INET6 && !tunnel->v4mapped)
+ if (l2tp_sk_is_v6(tunnel->sock))
error = inet6_csk_xmit(tunnel->sock, skb, NULL);
else
#endif
@@ -1193,6 +1200,15 @@ int l2tp_xmit_skb(struct l2tp_session *s
goto out_unlock;
}
+ /* The user-space may change the connection status for the user-space
+ * provided socket at run time: we must check it under the socket lock
+ */
+ if (tunnel->fd >= 0 && sk->sk_state != TCP_ESTABLISHED) {
+ kfree_skb(skb);
+ ret = NET_XMIT_DROP;
+ goto out_unlock;
+ }
+
/* Get routing info from the tunnel socket */
skb_dst_drop(skb);
skb_dst_set(skb, dst_clone(__sk_dst_check(sk, 0)));
@@ -1212,7 +1228,7 @@ int l2tp_xmit_skb(struct l2tp_session *s
/* Calculate UDP checksum if configured to do so */
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6 && !tunnel->v4mapped)
+ if (l2tp_sk_is_v6(sk))
udp6_set_csum(udp_get_no_check6_tx(sk),
skb, &inet6_sk(sk)->saddr,
&sk->sk_v6_daddr, udp_len);
@@ -1616,24 +1632,6 @@ int l2tp_tunnel_create(struct net *net,
if (cfg != NULL)
tunnel->debug = cfg->debug;
-#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6) {
- struct ipv6_pinfo *np = inet6_sk(sk);
-
- if (ipv6_addr_v4mapped(&np->saddr) &&
- ipv6_addr_v4mapped(&sk->sk_v6_daddr)) {
- struct inet_sock *inet = inet_sk(sk);
-
- tunnel->v4mapped = true;
- inet->inet_saddr = np->saddr.s6_addr32[3];
- inet->inet_rcv_saddr = sk->sk_v6_rcv_saddr.s6_addr32[3];
- inet->inet_daddr = sk->sk_v6_daddr.s6_addr32[3];
- } else {
- tunnel->v4mapped = false;
- }
- }
-#endif
-
/* Mark socket as an encapsulation socket. See net/ipv4/udp.c */
tunnel->encap = encap;
if (encap == L2TP_ENCAPTYPE_UDP) {
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -195,9 +195,6 @@ struct l2tp_tunnel {
struct sock *sock; /* Parent socket */
int fd; /* Parent fd, if tunnel socket
* was created by userspace */
-#if IS_ENABLED(CONFIG_IPV6)
- bool v4mapped;
-#endif
struct work_struct del_work;
Patches currently in stable-queue which might be from pabeni(a)redhat.com are
queue-4.14/l2tp-fix-races-with-ipv4-mapped-ipv6-addresses.patch
queue-4.14/netfilter-drop-template-ct-when-conntrack-is-skipped.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: Fix missing encryption refresh on Security Request
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-fix-missing-encryption-refresh-on-security-request.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 64e759f58f128730b97a3c3a26d283c075ad7c86 Mon Sep 17 00:00:00 2001
From: Szymon Janc <szymon.janc(a)codecoup.pl>
Date: Mon, 26 Feb 2018 15:41:53 +0100
Subject: Bluetooth: Fix missing encryption refresh on Security Request
From: Szymon Janc <szymon.janc(a)codecoup.pl>
commit 64e759f58f128730b97a3c3a26d283c075ad7c86 upstream.
If Security Request is received on connection that is already encrypted
with sufficient security master should perform encryption key refresh
procedure instead of just ignoring Slave Security Request
(Core Spec 5.0 Vol 3 Part H 2.4.6).
> ACL Data RX: Handle 3585 flags 0x02 dlen 6
SMP: Security Request (0x0b) len 1
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28
Handle: 3585
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
Long term key: 44264272a5c426a9e868f034cf0e69f3
> HCI Event: Command Status (0x0f) plen 4
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Encryption Key Refresh Complete (0x30) plen 3
Status: Success (0x00)
Handle: 3585
Signed-off-by: Szymon Janc <szymon.janc(a)codecoup.pl>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bluetooth/smp.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2287,8 +2287,14 @@ static u8 smp_cmd_security_req(struct l2
else
sec_level = authreq_to_seclevel(auth);
- if (smp_sufficient_security(hcon, sec_level, SMP_USE_LTK))
+ if (smp_sufficient_security(hcon, sec_level, SMP_USE_LTK)) {
+ /* If link is already encrypted with sufficient security we
+ * still need refresh encryption as per Core Spec 5.0 Vol 3,
+ * Part H 2.4.6
+ */
+ smp_ltk_encrypt(conn, hcon->sec_level);
return 0;
+ }
if (sec_level > hcon->pending_sec_level)
hcon->pending_sec_level = sec_level;
Patches currently in stable-queue which might be from szymon.janc(a)codecoup.pl are
queue-4.14/bluetooth-fix-missing-encryption-refresh-on-security-request.patch
This is a note to let you know that I've just added the patch titled
xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 19d7df69fdb2636856dc8919de72fc1bf8f79598 Mon Sep 17 00:00:00 2001
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Thu, 1 Feb 2018 08:49:23 +0100
Subject: xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
From: Steffen Klassert <steffen.klassert(a)secunet.com>
commit 19d7df69fdb2636856dc8919de72fc1bf8f79598 upstream.
We don't have a compat layer for xfrm, so userspace and kernel
structures have different sizes in this case. This results in
a broken configuration, so refuse to configure socket policies
when trying to insert from 32 bit userspace as we do it already
with policies inserted via netlink.
Reported-and-tested-by: syzbot+e1a1577ca8bcb47b769a(a)syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
[use is_compat_task() - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_state.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1845,6 +1845,11 @@ int xfrm_user_policy(struct sock *sk, in
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;
+#ifdef CONFIG_COMPAT
+ if (is_compat_task())
+ return -EOPNOTSUPP;
+#endif
+
if (!optval && !optlen) {
xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-3.18/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-3.18/xfrm-refuse-to-insert-32-bit-userspace-socket-policies-on-64-bit-systems.patch
queue-3.18/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: add and use xt_check_proc_name
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-x_tables-add-and-use-xt_check_proc_name.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b1d0a5d0cba4597c0394997b2d5fced3e3841b4e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Sat, 10 Mar 2018 01:15:45 +0100
Subject: netfilter: x_tables: add and use xt_check_proc_name
From: Florian Westphal <fw(a)strlen.de>
commit b1d0a5d0cba4597c0394997b2d5fced3e3841b4e upstream.
recent and hashlimit both create /proc files, but only check that
name is 0 terminated.
This can trigger WARN() from procfs when name is "" or "/".
Add helper for this and then use it for both.
Cc: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: Eric Dumazet <eric.dumazet(a)gmail.com>
Reported-by: <syzbot+0502b00edac2a0680b61(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/netfilter/x_tables.h | 2 ++
net/netfilter/x_tables.c | 30 ++++++++++++++++++++++++++++++
net/netfilter/xt_hashlimit.c | 5 +++--
net/netfilter/xt_recent.c | 6 +++---
4 files changed, 38 insertions(+), 5 deletions(-)
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -247,6 +247,8 @@ unsigned int *xt_alloc_entry_offsets(uns
bool xt_find_jump_offset(const unsigned int *offsets,
unsigned int target, unsigned int size);
+int xt_check_proc_name(const char *name, unsigned int size);
+
int xt_check_match(struct xt_mtchk_param *, unsigned int size, u_int8_t proto,
bool inv_proto);
int xt_check_target(struct xt_tgchk_param *, unsigned int size, u_int8_t proto,
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -367,6 +367,36 @@ textify_hooks(char *buf, size_t size, un
return buf;
}
+/**
+ * xt_check_proc_name - check that name is suitable for /proc file creation
+ *
+ * @name: file name candidate
+ * @size: length of buffer
+ *
+ * some x_tables modules wish to create a file in /proc.
+ * This function makes sure that the name is suitable for this
+ * purpose, it checks that name is NUL terminated and isn't a 'special'
+ * name, like "..".
+ *
+ * returns negative number on error or 0 if name is useable.
+ */
+int xt_check_proc_name(const char *name, unsigned int size)
+{
+ if (name[0] == '\0')
+ return -EINVAL;
+
+ if (strnlen(name, size) == size)
+ return -ENAMETOOLONG;
+
+ if (strcmp(name, ".") == 0 ||
+ strcmp(name, "..") == 0 ||
+ strchr(name, '/'))
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(xt_check_proc_name);
+
int xt_check_match(struct xt_mtchk_param *par,
unsigned int size, u_int8_t proto, bool inv_proto)
{
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -668,8 +668,9 @@ static int hashlimit_mt_check(const stru
if (info->cfg.gc_interval == 0 || info->cfg.expire == 0)
return -EINVAL;
- if (info->name[sizeof(info->name)-1] != '\0')
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
if (par->family == NFPROTO_IPV4) {
if (info->cfg.srcmask > 32 || info->cfg.dstmask > 32)
return -EINVAL;
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -355,9 +355,9 @@ static int recent_mt_check(const struct
info->hit_count, ip_pkt_list_tot);
return -EINVAL;
}
- if (info->name[0] == '\0' ||
- strnlen(info->name, XT_RECENT_NAME_LEN) == XT_RECENT_NAME_LEN)
- return -EINVAL;
+ ret = xt_check_proc_name(info->name, sizeof(info->name));
+ if (ret)
+ return ret;
mutex_lock(&recent_mutex);
t = recent_table_lookup(recent_net, info->name);
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-3.18/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-3.18/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-3.18/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
This is a note to let you know that I've just added the patch titled
netfilter: bridge: ebt_among: add more missing match size checks
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Fri, 9 Mar 2018 14:27:31 +0100
Subject: netfilter: bridge: ebt_among: add more missing match size checks
From: Florian Westphal <fw(a)strlen.de>
commit c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 upstream.
ebt_among is special, it has a dynamic match size and is exempt
from the central size checks.
commit c4585a2823edf ("bridge: ebt_among: add missing match size checks")
added validation for pool size, but missed fact that the macros
ebt_among_wh_src/dst can already return out-of-bound result because
they do not check value of wh_src/dst_ofs (an offset) vs. the size
of the match that userspace gave to us.
v2:
check that offset has correct alignment.
Paolo Abeni points out that we should also check that src/dst
wormhash arrays do not overlap, and src + length lines up with
start of dst (or vice versa).
v3: compact wormhash_sizes_valid() part
NB: Fixes tag is intentionally wrong, this bug exists from day
one when match was added for 2.6 kernel. Tag is there so stable
maintainers will notice this one too.
Tested with same rules from the earlier patch.
Fixes: c4585a2823edf ("bridge: ebt_among: add missing match size checks")
Reported-by: <syzbot+bdabab6f1983a03fc009(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bridge/netfilter/ebt_among.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
--- a/net/bridge/netfilter/ebt_among.c
+++ b/net/bridge/netfilter/ebt_among.c
@@ -177,6 +177,28 @@ static bool poolsize_invalid(const struc
return w && w->poolsize >= (INT_MAX / sizeof(struct ebt_mac_wormhash_tuple));
}
+static bool wormhash_offset_invalid(int off, unsigned int len)
+{
+ if (off == 0) /* not present */
+ return false;
+
+ if (off < (int)sizeof(struct ebt_among_info) ||
+ off % __alignof__(struct ebt_mac_wormhash))
+ return true;
+
+ off += sizeof(struct ebt_mac_wormhash);
+
+ return off > len;
+}
+
+static bool wormhash_sizes_valid(const struct ebt_mac_wormhash *wh, int a, int b)
+{
+ if (a == 0)
+ a = sizeof(struct ebt_among_info);
+
+ return ebt_mac_wormhash_size(wh) + a == b;
+}
+
static int ebt_among_mt_check(const struct xt_mtchk_param *par)
{
const struct ebt_among_info *info = par->matchinfo;
@@ -189,6 +211,10 @@ static int ebt_among_mt_check(const stru
if (expected_length > em->match_size)
return -EINVAL;
+ if (wormhash_offset_invalid(info->wh_dst_ofs, em->match_size) ||
+ wormhash_offset_invalid(info->wh_src_ofs, em->match_size))
+ return -EINVAL;
+
wh_dst = ebt_among_wh_dst(info);
if (poolsize_invalid(wh_dst))
return -EINVAL;
@@ -201,6 +227,14 @@ static int ebt_among_mt_check(const stru
if (poolsize_invalid(wh_src))
return -EINVAL;
+ if (info->wh_src_ofs < info->wh_dst_ofs) {
+ if (!wormhash_sizes_valid(wh_src, info->wh_src_ofs, info->wh_dst_ofs))
+ return -EINVAL;
+ } else {
+ if (!wormhash_sizes_valid(wh_dst, info->wh_dst_ofs, info->wh_src_ofs))
+ return -EINVAL;
+ }
+
expected_length += ebt_mac_wormhash_size(wh_src);
if (em->match_size != EBT_ALIGN(expected_length)) {
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-3.18/netfilter-x_tables-add-and-use-xt_check_proc_name.patch
queue-3.18/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
queue-3.18/netfilter-bridge-ebt_among-add-more-missing-match-size-checks.patch
This is a note to let you know that I've just added the patch titled
net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0dcd7876029b58770f769cbb7b484e88e4a305e5 Mon Sep 17 00:00:00 2001
From: Greg Hackmann <ghackmann(a)google.com>
Date: Wed, 7 Mar 2018 14:42:53 -0800
Subject: net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
From: Greg Hackmann <ghackmann(a)google.com>
commit 0dcd7876029b58770f769cbb7b484e88e4a305e5 upstream.
f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
__this_cpu_read() call inside ipcomp_alloc_tfms().
At the time, __this_cpu_read() required the caller to either not care
about races or to handle preemption/interrupt issues. 3.15 tightened
the rules around some per-cpu operations, and now __this_cpu_read()
should never be used in a preemptible context. On 3.15 and later, we
need to use this_cpu_read() instead.
syzkaller reported this leading to the following kernel BUG while
fuzzing sendmsg:
BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101
caller is ipcomp_init_state+0x185/0x990
CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 #154
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Call Trace:
dump_stack+0xb9/0x115
check_preemption_disabled+0x1cb/0x1f0
ipcomp_init_state+0x185/0x990
? __xfrm_init_state+0x876/0xc20
? lock_downgrade+0x5e0/0x5e0
ipcomp4_init_state+0xaa/0x7c0
__xfrm_init_state+0x3eb/0xc20
xfrm_init_state+0x19/0x60
pfkey_add+0x20df/0x36f0
? pfkey_broadcast+0x3dd/0x600
? pfkey_sock_destruct+0x340/0x340
? pfkey_seq_stop+0x80/0x80
? __skb_clone+0x236/0x750
? kmem_cache_alloc+0x1f6/0x260
? pfkey_sock_destruct+0x340/0x340
? pfkey_process+0x62a/0x6f0
pfkey_process+0x62a/0x6f0
? pfkey_send_new_mapping+0x11c0/0x11c0
? mutex_lock_io_nested+0x1390/0x1390
pfkey_sendmsg+0x383/0x750
? dump_sp+0x430/0x430
sock_sendmsg+0xc0/0x100
___sys_sendmsg+0x6c8/0x8b0
? copy_msghdr_from_user+0x3b0/0x3b0
? pagevec_lru_move_fn+0x144/0x1f0
? find_held_lock+0x32/0x1c0
? do_huge_pmd_anonymous_page+0xc43/0x11e0
? lock_downgrade+0x5e0/0x5e0
? get_kernel_page+0xb0/0xb0
? _raw_spin_unlock+0x29/0x40
? do_huge_pmd_anonymous_page+0x400/0x11e0
? __handle_mm_fault+0x553/0x2460
? __fget_light+0x163/0x1f0
? __sys_sendmsg+0xc7/0x170
__sys_sendmsg+0xc7/0x170
? SyS_shutdown+0x1a0/0x1a0
? __do_page_fault+0x5a0/0xca0
? lock_downgrade+0x5e0/0x5e0
SyS_sendmsg+0x27/0x40
? __sys_sendmsg+0x170/0x170
do_syscall_64+0x19f/0x640
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x7f0ee73dfb79
RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79
RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004
RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0
R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440
R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000
Signed-off-by: Greg Hackmann <ghackmann(a)google.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_ipcomp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -283,7 +283,7 @@ static struct crypto_comp * __percpu *ip
struct crypto_comp *tfm;
/* This can be any valid CPU ID so we don't need locking. */
- tfm = __this_cpu_read(*pos->tfms);
+ tfm = this_cpu_read(*pos->tfms);
if (!strcmp(crypto_comp_name(tfm), alg_name)) {
pos->users++;
Patches currently in stable-queue which might be from ghackmann(a)google.com are
queue-3.18/net-xfrm-use-preempt-safe-this_cpu_read-in-ipcomp_alloc_tfms.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: Fix missing encryption refresh on Security Request
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-fix-missing-encryption-refresh-on-security-request.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 64e759f58f128730b97a3c3a26d283c075ad7c86 Mon Sep 17 00:00:00 2001
From: Szymon Janc <szymon.janc(a)codecoup.pl>
Date: Mon, 26 Feb 2018 15:41:53 +0100
Subject: Bluetooth: Fix missing encryption refresh on Security Request
From: Szymon Janc <szymon.janc(a)codecoup.pl>
commit 64e759f58f128730b97a3c3a26d283c075ad7c86 upstream.
If Security Request is received on connection that is already encrypted
with sufficient security master should perform encryption key refresh
procedure instead of just ignoring Slave Security Request
(Core Spec 5.0 Vol 3 Part H 2.4.6).
> ACL Data RX: Handle 3585 flags 0x02 dlen 6
SMP: Security Request (0x0b) len 1
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28
Handle: 3585
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
Long term key: 44264272a5c426a9e868f034cf0e69f3
> HCI Event: Command Status (0x0f) plen 4
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Encryption Key Refresh Complete (0x30) plen 3
Status: Success (0x00)
Handle: 3585
Signed-off-by: Szymon Janc <szymon.janc(a)codecoup.pl>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/bluetooth/smp.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -1178,8 +1178,14 @@ static u8 smp_cmd_security_req(struct l2
else
sec_level = authreq_to_seclevel(auth);
- if (smp_sufficient_security(hcon, sec_level))
+ if (smp_sufficient_security(hcon, sec_level)) {
+ /* If link is already encrypted with sufficient security we
+ * still need refresh encryption as per Core Spec 5.0 Vol 3,
+ * Part H 2.4.6
+ */
+ smp_ltk_encrypt(conn, hcon->sec_level);
return 0;
+ }
if (sec_level > hcon->pending_sec_level)
hcon->pending_sec_level = sec_level;
Patches currently in stable-queue which might be from szymon.janc(a)codecoup.pl are
queue-3.18/bluetooth-fix-missing-encryption-refresh-on-security-request.patch
Hi,
Please add following patch to stable tree:
"Bluetooth: Fix missing encryption refresh on Security Request"
commit ID: 64e759f58f128730b97a3c3a26d283c075ad7c86
Reason:
This patch fix issue affecting Bluetooth qualification and was intended for
stable anyway, just miss to add CC stable@ to SoB area.
--
pozdrawiam
Szymon Janc
This is a note to let you know that I've just added the patch titled
xfrm_user: uncoditionally validate esn replay attribute struct
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d97ca5d714a5334aecadadf696875da40f1fbf3e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Mon, 12 Feb 2018 14:42:01 +0100
Subject: xfrm_user: uncoditionally validate esn replay attribute struct
From: Florian Westphal <fw(a)strlen.de>
commit d97ca5d714a5334aecadadf696875da40f1fbf3e upstream.
The sanity test added in ecd7918745234 can be bypassed, validation
only occurs if XFRM_STATE_ESN flag is set, but rest of code doesn't care
and just checks if the attribute itself is present.
So always validate. Alternative is to reject if we have the attribute
without the flag but that would change abi.
Reported-by: syzbot+0ab777c27d2bb7588f73(a)syzkaller.appspotmail.com
Cc: Mathias Krause <minipli(a)googlemail.com>
Fixes: ecd7918745234 ("xfrm_user: ensure user supplied esn replay window is valid")
Fixes: d8647b79c3b7e ("xfrm: Add user interface for esn and big anti-replay windows")
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_user.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -121,22 +121,17 @@ static inline int verify_replay(struct x
struct nlattr *rt = attrs[XFRMA_REPLAY_ESN_VAL];
struct xfrm_replay_state_esn *rs;
- if (p->flags & XFRM_STATE_ESN) {
- if (!rt)
- return -EINVAL;
-
- rs = nla_data(rt);
+ if (!rt)
+ return (p->flags & XFRM_STATE_ESN) ? -EINVAL : 0;
- if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
- return -EINVAL;
+ rs = nla_data(rt);
- if (nla_len(rt) < xfrm_replay_state_esn_len(rs) &&
- nla_len(rt) != sizeof(*rs))
- return -EINVAL;
- }
+ if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
+ return -EINVAL;
- if (!rt)
- return 0;
+ if (nla_len(rt) < xfrm_replay_state_esn_len(rs) &&
+ nla_len(rt) != sizeof(*rs))
+ return -EINVAL;
/* As only ESP and AH support ESN feature. */
if ((p->id.proto != IPPROTO_ESP) && (p->id.proto != IPPROTO_AH))
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.9/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Introduce safer rdma_addr_size() variants
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 84652aefb347297aa08e91e283adf7b18f77c2d5 Mon Sep 17 00:00:00 2001
From: Roland Dreier <roland(a)purestorage.com>
Date: Wed, 28 Mar 2018 11:27:22 -0700
Subject: RDMA/ucma: Introduce safer rdma_addr_size() variants
From: Roland Dreier <roland(a)purestorage.com>
commit 84652aefb347297aa08e91e283adf7b18f77c2d5 upstream.
There are several places in the ucma ABI where userspace can pass in a
sockaddr but set the address family to AF_IB. When that happens,
rdma_addr_size() will return a size bigger than sizeof struct sockaddr_in6,
and the ucma kernel code might end up copying past the end of a buffer
not sized for a struct sockaddr_ib.
Fix this by introducing new variants
int rdma_addr_size_in6(struct sockaddr_in6 *addr);
int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
that are type-safe for the types used in the ucma ABI and return 0 if the
size computed is bigger than the size of the type passed in. We can use
these new variants to check what size userspace has passed in before
copying any addresses.
Reported-by: <syzbot+6800425d54ed3ed8135d(a)syzkaller.appspotmail.com>
Signed-off-by: Roland Dreier <roland(a)purestorage.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/addr.c | 16 ++++++++++++++++
drivers/infiniband/core/ucma.c | 34 +++++++++++++++++-----------------
include/rdma/ib_addr.h | 2 ++
3 files changed, 35 insertions(+), 17 deletions(-)
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -209,6 +209,22 @@ int rdma_addr_size(struct sockaddr *addr
}
EXPORT_SYMBOL(rdma_addr_size);
+int rdma_addr_size_in6(struct sockaddr_in6 *addr)
+{
+ int ret = rdma_addr_size((struct sockaddr *) addr);
+
+ return ret <= sizeof(*addr) ? ret : 0;
+}
+EXPORT_SYMBOL(rdma_addr_size_in6);
+
+int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr)
+{
+ int ret = rdma_addr_size((struct sockaddr *) addr);
+
+ return ret <= sizeof(*addr) ? ret : 0;
+}
+EXPORT_SYMBOL(rdma_addr_size_kss);
+
static struct rdma_addr_client self;
void rdma_addr_register_client(struct rdma_addr_client *client)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -630,6 +630,9 @@ static ssize_t ucma_bind_ip(struct ucma_
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
+ if (!rdma_addr_size_in6(&cmd.addr))
+ return -EINVAL;
+
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
@@ -643,22 +646,21 @@ static ssize_t ucma_bind(struct ucma_fil
int in_len, int out_len)
{
struct rdma_ucm_bind cmd;
- struct sockaddr *addr;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- addr = (struct sockaddr *) &cmd.addr;
- if (cmd.reserved || !cmd.addr_size || (cmd.addr_size != rdma_addr_size(addr)))
+ if (cmd.reserved || !cmd.addr_size ||
+ cmd.addr_size != rdma_addr_size_kss(&cmd.addr))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_bind_addr(ctx->cm_id, addr);
+ ret = rdma_bind_addr(ctx->cm_id, (struct sockaddr *) &cmd.addr);
ucma_put_ctx(ctx);
return ret;
}
@@ -668,23 +670,22 @@ static ssize_t ucma_resolve_ip(struct uc
int in_len, int out_len)
{
struct rdma_ucm_resolve_ip cmd;
- struct sockaddr *src, *dst;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- src = (struct sockaddr *) &cmd.src_addr;
- dst = (struct sockaddr *) &cmd.dst_addr;
- if (!rdma_addr_size(src) || !rdma_addr_size(dst))
+ if (!rdma_addr_size_in6(&cmd.src_addr) ||
+ !rdma_addr_size_in6(&cmd.dst_addr))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_resolve_addr(ctx->cm_id, src, dst, cmd.timeout_ms);
+ ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
+ (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
ucma_put_ctx(ctx);
return ret;
}
@@ -694,24 +695,23 @@ static ssize_t ucma_resolve_addr(struct
int in_len, int out_len)
{
struct rdma_ucm_resolve_addr cmd;
- struct sockaddr *src, *dst;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- src = (struct sockaddr *) &cmd.src_addr;
- dst = (struct sockaddr *) &cmd.dst_addr;
- if (cmd.reserved || (cmd.src_size && (cmd.src_size != rdma_addr_size(src))) ||
- !cmd.dst_size || (cmd.dst_size != rdma_addr_size(dst)))
+ if (cmd.reserved ||
+ (cmd.src_size && (cmd.src_size != rdma_addr_size_kss(&cmd.src_addr))) ||
+ !cmd.dst_size || (cmd.dst_size != rdma_addr_size_kss(&cmd.dst_addr)))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_resolve_addr(ctx->cm_id, src, dst, cmd.timeout_ms);
+ ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
+ (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
ucma_put_ctx(ctx);
return ret;
}
@@ -1414,7 +1414,7 @@ static ssize_t ucma_join_ip_multicast(st
join_cmd.response = cmd.response;
join_cmd.uid = cmd.uid;
join_cmd.id = cmd.id;
- join_cmd.addr_size = rdma_addr_size((struct sockaddr *) &cmd.addr);
+ join_cmd.addr_size = rdma_addr_size_in6(&cmd.addr);
if (!join_cmd.addr_size)
return -EINVAL;
@@ -1433,7 +1433,7 @@ static ssize_t ucma_join_multicast(struc
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- if (!rdma_addr_size((struct sockaddr *)&cmd.addr))
+ if (!rdma_addr_size_kss(&cmd.addr))
return -EINVAL;
return ucma_process_join(file, &cmd, out_len);
--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -129,6 +129,8 @@ int rdma_copy_addr(struct rdma_dev_addr
const unsigned char *dst_dev_addr);
int rdma_addr_size(struct sockaddr *addr);
+int rdma_addr_size_in6(struct sockaddr_in6 *addr);
+int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
int rdma_addr_find_smac_by_sgid(union ib_gid *sgid, u8 *smac, u16 *vlan_id);
int rdma_addr_find_l2_eth_by_grh(const union ib_gid *sgid,
Patches currently in stable-queue which might be from roland(a)purestorage.com are
queue-4.9/rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Fix use-after-free access in ucma_close
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ed65a4dc22083e73bac599ded6a262318cad7baf Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Mon, 19 Mar 2018 14:20:15 +0200
Subject: RDMA/ucma: Fix use-after-free access in ucma_close
From: Leon Romanovsky <leonro(a)mellanox.com>
commit ed65a4dc22083e73bac599ded6a262318cad7baf upstream.
The error in ucma_create_id() left ctx in the list of contexts belong
to ucma file descriptor. The attempt to close this file descriptor causes
to use-after-free accesses while iterating over such list.
Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Reported-by: <syzbot+dcfd344365a56fbebd0f(a)syzkaller.appspotmail.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Reviewed-by: Sean Hefty <sean.hefty(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/ucma.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -495,6 +495,9 @@ err1:
mutex_lock(&mut);
idr_remove(&ctx_idr, ctx->id);
mutex_unlock(&mut);
+ mutex_lock(&file->mut);
+ list_del(&ctx->list);
+ mutex_unlock(&file->mut);
kfree(ctx);
return ret;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.9/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.9/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.9/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.9/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.9/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Check that device exists prior to accessing it
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c8d3bcbfc5eab3f01cf373d039af725f3b488813 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Sun, 25 Mar 2018 11:39:05 +0300
Subject: RDMA/ucma: Check that device exists prior to accessing it
From: Leon Romanovsky <leonro(a)mellanox.com>
commit c8d3bcbfc5eab3f01cf373d039af725f3b488813 upstream.
Ensure that device exists prior to accessing its properties.
Reported-by: <syzbot+71655d44855ac3e76366(a)syzkaller.appspotmail.com>
Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/ucma.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -1317,7 +1317,7 @@ static ssize_t ucma_notify(struct ucma_f
{
struct rdma_ucm_notify cmd;
struct ucma_context *ctx;
- int ret;
+ int ret = -EINVAL;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
@@ -1326,7 +1326,9 @@ static ssize_t ucma_notify(struct ucma_f
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_notify(ctx->cm_id, (enum ib_event_type) cmd.event);
+ if (ctx->cm_id->device)
+ ret = rdma_notify(ctx->cm_id, (enum ib_event_type)cmd.event);
+
ucma_put_ctx(ctx);
return ret;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.9/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.9/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.9/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.9/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.9/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
xfrm_user: uncoditionally validate esn replay attribute struct
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d97ca5d714a5334aecadadf696875da40f1fbf3e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Mon, 12 Feb 2018 14:42:01 +0100
Subject: xfrm_user: uncoditionally validate esn replay attribute struct
From: Florian Westphal <fw(a)strlen.de>
commit d97ca5d714a5334aecadadf696875da40f1fbf3e upstream.
The sanity test added in ecd7918745234 can be bypassed, validation
only occurs if XFRM_STATE_ESN flag is set, but rest of code doesn't care
and just checks if the attribute itself is present.
So always validate. Alternative is to reject if we have the attribute
without the flag but that would change abi.
Reported-by: syzbot+0ab777c27d2bb7588f73(a)syzkaller.appspotmail.com
Cc: Mathias Krause <minipli(a)googlemail.com>
Fixes: ecd7918745234 ("xfrm_user: ensure user supplied esn replay window is valid")
Fixes: d8647b79c3b7e ("xfrm: Add user interface for esn and big anti-replay windows")
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_user.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -121,22 +121,17 @@ static inline int verify_replay(struct x
struct nlattr *rt = attrs[XFRMA_REPLAY_ESN_VAL];
struct xfrm_replay_state_esn *rs;
- if (p->flags & XFRM_STATE_ESN) {
- if (!rt)
- return -EINVAL;
-
- rs = nla_data(rt);
+ if (!rt)
+ return (p->flags & XFRM_STATE_ESN) ? -EINVAL : 0;
- if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
- return -EINVAL;
+ rs = nla_data(rt);
- if (nla_len(rt) < xfrm_replay_state_esn_len(rs) &&
- nla_len(rt) != sizeof(*rs))
- return -EINVAL;
- }
+ if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
+ return -EINVAL;
- if (!rt)
- return 0;
+ if (nla_len(rt) < xfrm_replay_state_esn_len(rs) &&
+ nla_len(rt) != sizeof(*rs))
+ return -EINVAL;
/* As only ESP and AH support ESN feature. */
if ((p->id.proto != IPPROTO_ESP) && (p->id.proto != IPPROTO_AH))
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.4/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
This is a note to let you know that I've just added the patch titled
tty: provide tty_name() even without CONFIG_TTY
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tty-provide-tty_name-even-without-config_tty.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 188e3c5cd2b672620291e64a21f1598fe91e40b6 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 27 Apr 2016 11:56:04 +0200
Subject: tty: provide tty_name() even without CONFIG_TTY
From: Arnd Bergmann <arnd(a)arndb.de>
commit 188e3c5cd2b672620291e64a21f1598fe91e40b6 upstream.
The audit subsystem just started printing the name of the tty,
but that causes a build failure when CONFIG_TTY is disabled:
kernel/built-in.o: In function `audit_log_task_info':
memremap.c:(.text+0x5e34c): undefined reference to `tty_name'
kernel/built-in.o: In function `audit_set_loginuid':
memremap.c:(.text+0x63b34): undefined reference to `tty_name'
This adds tty_name() to the list of functions that are provided
as trivial stubs in that configuration.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Fixes: db0a6fb5d97a ("audit: add tty field to LOGIN event")
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
[natechancellor: tty_paranoia_check still exists]
Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/tty.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -372,6 +372,7 @@ extern void proc_clear_tty(struct task_s
extern struct tty_struct *get_current_tty(void);
/* tty_io.c */
extern int __init tty_init(void);
+extern const char *tty_name(const struct tty_struct *tty);
#else
static inline void console_init(void)
{ }
@@ -392,6 +393,8 @@ static inline struct tty_struct *get_cur
/* tty_io.c */
static inline int __init tty_init(void)
{ return 0; }
+static inline const char *tty_name(const struct tty_struct *tty)
+{ return "(none)"; }
#endif
extern void tty_write_flush(struct tty_struct *);
@@ -420,7 +423,6 @@ static inline struct tty_struct *tty_kre
extern int tty_paranoia_check(struct tty_struct *tty, struct inode *inode,
const char *routine);
-extern const char *tty_name(const struct tty_struct *tty);
extern void tty_wait_until_sent(struct tty_struct *tty, long timeout);
extern int __tty_check_change(struct tty_struct *tty, int sig);
extern int tty_check_change(struct tty_struct *tty);
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/tty-provide-tty_name-even-without-config_tty.patch
This is a note to let you know that I've just added the patch titled
selinux: Remove redundant check for unknown labeling behavior
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 270e8573145a26de924e2dc644596332d400445b Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Fri, 19 May 2017 10:09:32 -0700
Subject: selinux: Remove redundant check for unknown labeling behavior
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 270e8573145a26de924e2dc644596332d400445b upstream.
The check is already performed in ocontext_read() when the policy is
loaded. Removing the array also fixes the following warning when
building with clang:
security/selinux/hooks.c:338:20: error: variable 'labeling_behaviors'
is not needed and will not be emitted
[-Werror,-Wunneeded-internal-declaration]
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Acked-by: Stephen Smalley <sds(a)tycho.nsa.gov>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
[natechancellor: inode_doinit_with_dentry still present]
Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/hooks.c | 16 ----------------
1 file changed, 16 deletions(-)
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -333,18 +333,6 @@ static void superblock_free_security(str
kfree(sbsec);
}
-/* The file system's label must be initialized prior to use. */
-
-static const char *labeling_behaviors[7] = {
- "uses xattr",
- "uses transition SIDs",
- "uses task SIDs",
- "uses genfs_contexts",
- "not configured for labeling",
- "uses mountpoint labeling",
- "uses native labeling",
-};
-
static int inode_doinit_with_dentry(struct inode *inode, struct dentry *opt_dentry);
static inline int inode_doinit(struct inode *inode)
@@ -456,10 +444,6 @@ static int sb_finish_set_opts(struct sup
}
}
- if (sbsec->behavior > ARRAY_SIZE(labeling_behaviors))
- printk(KERN_ERR "SELinux: initialized (dev %s, type %s), unknown behavior\n",
- sb->s_id, sb->s_type->name);
-
sbsec->flags |= SE_SBINITIALIZED;
if (selinux_is_sblabel_mnt(sb))
sbsec->flags |= SBLABEL_MNT;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/dm-ioctl-remove-double-parentheses.patch
queue-4.4/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.4/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.4/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.4/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.4/netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Introduce safer rdma_addr_size() variants
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 84652aefb347297aa08e91e283adf7b18f77c2d5 Mon Sep 17 00:00:00 2001
From: Roland Dreier <roland(a)purestorage.com>
Date: Wed, 28 Mar 2018 11:27:22 -0700
Subject: RDMA/ucma: Introduce safer rdma_addr_size() variants
From: Roland Dreier <roland(a)purestorage.com>
commit 84652aefb347297aa08e91e283adf7b18f77c2d5 upstream.
There are several places in the ucma ABI where userspace can pass in a
sockaddr but set the address family to AF_IB. When that happens,
rdma_addr_size() will return a size bigger than sizeof struct sockaddr_in6,
and the ucma kernel code might end up copying past the end of a buffer
not sized for a struct sockaddr_ib.
Fix this by introducing new variants
int rdma_addr_size_in6(struct sockaddr_in6 *addr);
int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
that are type-safe for the types used in the ucma ABI and return 0 if the
size computed is bigger than the size of the type passed in. We can use
these new variants to check what size userspace has passed in before
copying any addresses.
Reported-by: <syzbot+6800425d54ed3ed8135d(a)syzkaller.appspotmail.com>
Signed-off-by: Roland Dreier <roland(a)purestorage.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/addr.c | 16 ++++++++++++++++
drivers/infiniband/core/ucma.c | 34 +++++++++++++++++-----------------
include/rdma/ib_addr.h | 2 ++
3 files changed, 35 insertions(+), 17 deletions(-)
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -86,6 +86,22 @@ int rdma_addr_size(struct sockaddr *addr
}
EXPORT_SYMBOL(rdma_addr_size);
+int rdma_addr_size_in6(struct sockaddr_in6 *addr)
+{
+ int ret = rdma_addr_size((struct sockaddr *) addr);
+
+ return ret <= sizeof(*addr) ? ret : 0;
+}
+EXPORT_SYMBOL(rdma_addr_size_in6);
+
+int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr)
+{
+ int ret = rdma_addr_size((struct sockaddr *) addr);
+
+ return ret <= sizeof(*addr) ? ret : 0;
+}
+EXPORT_SYMBOL(rdma_addr_size_kss);
+
static struct rdma_addr_client self;
void rdma_addr_register_client(struct rdma_addr_client *client)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -629,6 +629,9 @@ static ssize_t ucma_bind_ip(struct ucma_
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
+ if (!rdma_addr_size_in6(&cmd.addr))
+ return -EINVAL;
+
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
@@ -642,22 +645,21 @@ static ssize_t ucma_bind(struct ucma_fil
int in_len, int out_len)
{
struct rdma_ucm_bind cmd;
- struct sockaddr *addr;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- addr = (struct sockaddr *) &cmd.addr;
- if (cmd.reserved || !cmd.addr_size || (cmd.addr_size != rdma_addr_size(addr)))
+ if (cmd.reserved || !cmd.addr_size ||
+ cmd.addr_size != rdma_addr_size_kss(&cmd.addr))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_bind_addr(ctx->cm_id, addr);
+ ret = rdma_bind_addr(ctx->cm_id, (struct sockaddr *) &cmd.addr);
ucma_put_ctx(ctx);
return ret;
}
@@ -667,23 +669,22 @@ static ssize_t ucma_resolve_ip(struct uc
int in_len, int out_len)
{
struct rdma_ucm_resolve_ip cmd;
- struct sockaddr *src, *dst;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- src = (struct sockaddr *) &cmd.src_addr;
- dst = (struct sockaddr *) &cmd.dst_addr;
- if (!rdma_addr_size(src) || !rdma_addr_size(dst))
+ if (!rdma_addr_size_in6(&cmd.src_addr) ||
+ !rdma_addr_size_in6(&cmd.dst_addr))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_resolve_addr(ctx->cm_id, src, dst, cmd.timeout_ms);
+ ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
+ (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
ucma_put_ctx(ctx);
return ret;
}
@@ -693,24 +694,23 @@ static ssize_t ucma_resolve_addr(struct
int in_len, int out_len)
{
struct rdma_ucm_resolve_addr cmd;
- struct sockaddr *src, *dst;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- src = (struct sockaddr *) &cmd.src_addr;
- dst = (struct sockaddr *) &cmd.dst_addr;
- if (cmd.reserved || (cmd.src_size && (cmd.src_size != rdma_addr_size(src))) ||
- !cmd.dst_size || (cmd.dst_size != rdma_addr_size(dst)))
+ if (cmd.reserved ||
+ (cmd.src_size && (cmd.src_size != rdma_addr_size_kss(&cmd.src_addr))) ||
+ !cmd.dst_size || (cmd.dst_size != rdma_addr_size_kss(&cmd.dst_addr)))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_resolve_addr(ctx->cm_id, src, dst, cmd.timeout_ms);
+ ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
+ (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
ucma_put_ctx(ctx);
return ret;
}
@@ -1404,7 +1404,7 @@ static ssize_t ucma_join_ip_multicast(st
join_cmd.response = cmd.response;
join_cmd.uid = cmd.uid;
join_cmd.id = cmd.id;
- join_cmd.addr_size = rdma_addr_size((struct sockaddr *) &cmd.addr);
+ join_cmd.addr_size = rdma_addr_size_in6(&cmd.addr);
if (!join_cmd.addr_size)
return -EINVAL;
@@ -1423,7 +1423,7 @@ static ssize_t ucma_join_multicast(struc
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- if (!rdma_addr_size((struct sockaddr *)&cmd.addr))
+ if (!rdma_addr_size_kss(&cmd.addr))
return -EINVAL;
return ucma_process_join(file, &cmd, out_len);
--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -123,6 +123,8 @@ int rdma_copy_addr(struct rdma_dev_addr
const unsigned char *dst_dev_addr);
int rdma_addr_size(struct sockaddr *addr);
+int rdma_addr_size_in6(struct sockaddr_in6 *addr);
+int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
int rdma_addr_find_smac_by_sgid(union ib_gid *sgid, u8 *smac, u16 *vlan_id);
int rdma_addr_find_dmac_by_grh(const union ib_gid *sgid, const union ib_gid *dgid,
Patches currently in stable-queue which might be from roland(a)purestorage.com are
queue-4.4/rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Fix use-after-free access in ucma_close
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ed65a4dc22083e73bac599ded6a262318cad7baf Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Mon, 19 Mar 2018 14:20:15 +0200
Subject: RDMA/ucma: Fix use-after-free access in ucma_close
From: Leon Romanovsky <leonro(a)mellanox.com>
commit ed65a4dc22083e73bac599ded6a262318cad7baf upstream.
The error in ucma_create_id() left ctx in the list of contexts belong
to ucma file descriptor. The attempt to close this file descriptor causes
to use-after-free accesses while iterating over such list.
Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Reported-by: <syzbot+dcfd344365a56fbebd0f(a)syzkaller.appspotmail.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Reviewed-by: Sean Hefty <sean.hefty(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/ucma.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -494,6 +494,9 @@ err1:
mutex_lock(&mut);
idr_remove(&ctx_idr, ctx->id);
mutex_unlock(&mut);
+ mutex_lock(&file->mut);
+ list_del(&ctx->list);
+ mutex_unlock(&file->mut);
kfree(ctx);
return ret;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.4/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.4/rdma-ucma-don-t-allow-join-attempts-for-unsupported-af-family.patch
queue-4.4/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.4/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.4/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.4/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Check that device exists prior to accessing it
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c8d3bcbfc5eab3f01cf373d039af725f3b488813 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Sun, 25 Mar 2018 11:39:05 +0300
Subject: RDMA/ucma: Check that device exists prior to accessing it
From: Leon Romanovsky <leonro(a)mellanox.com>
commit c8d3bcbfc5eab3f01cf373d039af725f3b488813 upstream.
Ensure that device exists prior to accessing its properties.
Reported-by: <syzbot+71655d44855ac3e76366(a)syzkaller.appspotmail.com>
Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/ucma.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -1316,7 +1316,7 @@ static ssize_t ucma_notify(struct ucma_f
{
struct rdma_ucm_notify cmd;
struct ucma_context *ctx;
- int ret;
+ int ret = -EINVAL;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
@@ -1325,7 +1325,9 @@ static ssize_t ucma_notify(struct ucma_f
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_notify(ctx->cm_id, (enum ib_event_type) cmd.event);
+ if (ctx->cm_id->device)
+ ret = rdma_notify(ctx->cm_id, (enum ib_event_type)cmd.event);
+
ucma_put_ctx(ctx);
return ret;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.4/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.4/rdma-ucma-don-t-allow-join-attempts-for-unsupported-af-family.patch
queue-4.4/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.4/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.4/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.4/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
netfilter: ctnetlink: Make some parameters integer to avoid enum mismatch
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a2b7cbdd2559aff06cebc28a7150f81c307a90d3 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Wed, 19 Apr 2017 11:39:20 -0700
Subject: netfilter: ctnetlink: Make some parameters integer to avoid enum mismatch
From: Matthias Kaehlcke <mka(a)chromium.org>
commit a2b7cbdd2559aff06cebc28a7150f81c307a90d3 upstream.
Not all parameters passed to ctnetlink_parse_tuple() and
ctnetlink_exp_dump_tuple() match the enum type in the signatures of these
functions. Since this is intended change the argument type of to be an
unsigned integer value.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
[natechancellor: ctnetlink_exp_dump_tuple is still inline]
Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/nf_conntrack_netlink.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -999,9 +999,8 @@ static const struct nla_policy tuple_nla
static int
ctnetlink_parse_tuple(const struct nlattr * const cda[],
- struct nf_conntrack_tuple *tuple,
- enum ctattr_type type, u_int8_t l3num,
- struct nf_conntrack_zone *zone)
+ struct nf_conntrack_tuple *tuple, u32 type,
+ u_int8_t l3num, struct nf_conntrack_zone *zone)
{
struct nlattr *tb[CTA_TUPLE_MAX+1];
int err;
@@ -2416,7 +2415,7 @@ static struct nfnl_ct_hook ctnetlink_glu
static inline int
ctnetlink_exp_dump_tuple(struct sk_buff *skb,
const struct nf_conntrack_tuple *tuple,
- enum ctattr_expect type)
+ u32 type)
{
struct nlattr *nest_parms;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/dm-ioctl-remove-double-parentheses.patch
queue-4.4/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.4/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.4/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.4/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.4/netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
arm64: avoid overflow in VA_START and PAGE_OFFSET
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-avoid-overflow-in-va_start-and-page_offset.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 82cd588052815eb4146f9f7c5347ca5e32c56360 Mon Sep 17 00:00:00 2001
From: Nick Desaulniers <ndesaulniers(a)google.com>
Date: Thu, 3 Aug 2017 11:03:58 -0700
Subject: arm64: avoid overflow in VA_START and PAGE_OFFSET
From: Nick Desaulniers <ndesaulniers(a)google.com>
commit 82cd588052815eb4146f9f7c5347ca5e32c56360 upstream.
The bitmask used to define these values produces overflow, as seen by
this compiler warning:
arch/arm64/kernel/head.S:47:8: warning:
integer overflow in preprocessor expression
#elif (PAGE_OFFSET & 0x1fffff) != 0
^~~~~~~~~~~
arch/arm64/include/asm/memory.h:52:46: note:
expanded from macro 'PAGE_OFFSET'
#define PAGE_OFFSET (UL(0xffffffffffffffff) << (VA_BITS -
1))
~~~~~~~~~~~~~~~~~~ ^
It would be preferrable to use GENMASK_ULL() instead, but it's not set
up to be used from assembly (the UL() macro token pastes UL suffixes
when not included in assembly sources).
Suggested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Suggested-by: Yury Norov <ynorov(a)caviumnetworks.com>
Suggested-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
[natechancellor: KIMAGE_VADDR doesn't exist]
Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/memory.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -49,8 +49,10 @@
* and PAGE_OFFSET - it must be within 128MB of the kernel text.
*/
#define VA_BITS (CONFIG_ARM64_VA_BITS)
-#define VA_START (UL(0xffffffffffffffff) << VA_BITS)
-#define PAGE_OFFSET (UL(0xffffffffffffffff) << (VA_BITS - 1))
+#define VA_START (UL(0xffffffffffffffff) - \
+ (UL(1) << VA_BITS) + 1)
+#define PAGE_OFFSET (UL(0xffffffffffffffff) - \
+ (UL(1) << (VA_BITS - 1)) + 1)
#define MODULES_END (PAGE_OFFSET)
#define MODULES_VADDR (MODULES_END - SZ_64M)
#define PCI_IO_END (MODULES_VADDR - SZ_2M)
Patches currently in stable-queue which might be from ndesaulniers(a)google.com are
queue-4.4/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.4/netfilter-nf_nat_h323-fix-logical-not-parentheses-warning.patch
This is a note to let you know that I've just added the patch titled
xfrm_user: uncoditionally validate esn replay attribute struct
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d97ca5d714a5334aecadadf696875da40f1fbf3e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Mon, 12 Feb 2018 14:42:01 +0100
Subject: xfrm_user: uncoditionally validate esn replay attribute struct
From: Florian Westphal <fw(a)strlen.de>
commit d97ca5d714a5334aecadadf696875da40f1fbf3e upstream.
The sanity test added in ecd7918745234 can be bypassed, validation
only occurs if XFRM_STATE_ESN flag is set, but rest of code doesn't care
and just checks if the attribute itself is present.
So always validate. Alternative is to reject if we have the attribute
without the flag but that would change abi.
Reported-by: syzbot+0ab777c27d2bb7588f73(a)syzkaller.appspotmail.com
Cc: Mathias Krause <minipli(a)googlemail.com>
Fixes: ecd7918745234 ("xfrm_user: ensure user supplied esn replay window is valid")
Fixes: d8647b79c3b7e ("xfrm: Add user interface for esn and big anti-replay windows")
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_user.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -121,22 +121,17 @@ static inline int verify_replay(struct x
struct nlattr *rt = attrs[XFRMA_REPLAY_ESN_VAL];
struct xfrm_replay_state_esn *rs;
- if (p->flags & XFRM_STATE_ESN) {
- if (!rt)
- return -EINVAL;
-
- rs = nla_data(rt);
+ if (!rt)
+ return (p->flags & XFRM_STATE_ESN) ? -EINVAL : 0;
- if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
- return -EINVAL;
+ rs = nla_data(rt);
- if (nla_len(rt) < xfrm_replay_state_esn_len(rs) &&
- nla_len(rt) != sizeof(*rs))
- return -EINVAL;
- }
+ if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
+ return -EINVAL;
- if (!rt)
- return 0;
+ if (nla_len(rt) < xfrm_replay_state_esn_len(rs) &&
+ nla_len(rt) != sizeof(*rs))
+ return -EINVAL;
/* As only ESP and AH support ESN feature. */
if ((p->id.proto != IPPROTO_ESP) && (p->id.proto != IPPROTO_AH))
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.14/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Introduce safer rdma_addr_size() variants
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 84652aefb347297aa08e91e283adf7b18f77c2d5 Mon Sep 17 00:00:00 2001
From: Roland Dreier <roland(a)purestorage.com>
Date: Wed, 28 Mar 2018 11:27:22 -0700
Subject: RDMA/ucma: Introduce safer rdma_addr_size() variants
From: Roland Dreier <roland(a)purestorage.com>
commit 84652aefb347297aa08e91e283adf7b18f77c2d5 upstream.
There are several places in the ucma ABI where userspace can pass in a
sockaddr but set the address family to AF_IB. When that happens,
rdma_addr_size() will return a size bigger than sizeof struct sockaddr_in6,
and the ucma kernel code might end up copying past the end of a buffer
not sized for a struct sockaddr_ib.
Fix this by introducing new variants
int rdma_addr_size_in6(struct sockaddr_in6 *addr);
int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
that are type-safe for the types used in the ucma ABI and return 0 if the
size computed is bigger than the size of the type passed in. We can use
these new variants to check what size userspace has passed in before
copying any addresses.
Reported-by: <syzbot+6800425d54ed3ed8135d(a)syzkaller.appspotmail.com>
Signed-off-by: Roland Dreier <roland(a)purestorage.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/addr.c | 16 ++++++++++++++++
drivers/infiniband/core/ucma.c | 34 +++++++++++++++++-----------------
include/rdma/ib_addr.h | 2 ++
3 files changed, 35 insertions(+), 17 deletions(-)
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -207,6 +207,22 @@ int rdma_addr_size(struct sockaddr *addr
}
EXPORT_SYMBOL(rdma_addr_size);
+int rdma_addr_size_in6(struct sockaddr_in6 *addr)
+{
+ int ret = rdma_addr_size((struct sockaddr *) addr);
+
+ return ret <= sizeof(*addr) ? ret : 0;
+}
+EXPORT_SYMBOL(rdma_addr_size_in6);
+
+int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr)
+{
+ int ret = rdma_addr_size((struct sockaddr *) addr);
+
+ return ret <= sizeof(*addr) ? ret : 0;
+}
+EXPORT_SYMBOL(rdma_addr_size_kss);
+
static struct rdma_addr_client self;
void rdma_addr_register_client(struct rdma_addr_client *client)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -632,6 +632,9 @@ static ssize_t ucma_bind_ip(struct ucma_
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
+ if (!rdma_addr_size_in6(&cmd.addr))
+ return -EINVAL;
+
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
@@ -645,22 +648,21 @@ static ssize_t ucma_bind(struct ucma_fil
int in_len, int out_len)
{
struct rdma_ucm_bind cmd;
- struct sockaddr *addr;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- addr = (struct sockaddr *) &cmd.addr;
- if (cmd.reserved || !cmd.addr_size || (cmd.addr_size != rdma_addr_size(addr)))
+ if (cmd.reserved || !cmd.addr_size ||
+ cmd.addr_size != rdma_addr_size_kss(&cmd.addr))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_bind_addr(ctx->cm_id, addr);
+ ret = rdma_bind_addr(ctx->cm_id, (struct sockaddr *) &cmd.addr);
ucma_put_ctx(ctx);
return ret;
}
@@ -670,23 +672,22 @@ static ssize_t ucma_resolve_ip(struct uc
int in_len, int out_len)
{
struct rdma_ucm_resolve_ip cmd;
- struct sockaddr *src, *dst;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- src = (struct sockaddr *) &cmd.src_addr;
- dst = (struct sockaddr *) &cmd.dst_addr;
- if (!rdma_addr_size(src) || !rdma_addr_size(dst))
+ if (!rdma_addr_size_in6(&cmd.src_addr) ||
+ !rdma_addr_size_in6(&cmd.dst_addr))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_resolve_addr(ctx->cm_id, src, dst, cmd.timeout_ms);
+ ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
+ (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
ucma_put_ctx(ctx);
return ret;
}
@@ -696,24 +697,23 @@ static ssize_t ucma_resolve_addr(struct
int in_len, int out_len)
{
struct rdma_ucm_resolve_addr cmd;
- struct sockaddr *src, *dst;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- src = (struct sockaddr *) &cmd.src_addr;
- dst = (struct sockaddr *) &cmd.dst_addr;
- if (cmd.reserved || (cmd.src_size && (cmd.src_size != rdma_addr_size(src))) ||
- !cmd.dst_size || (cmd.dst_size != rdma_addr_size(dst)))
+ if (cmd.reserved ||
+ (cmd.src_size && (cmd.src_size != rdma_addr_size_kss(&cmd.src_addr))) ||
+ !cmd.dst_size || (cmd.dst_size != rdma_addr_size_kss(&cmd.dst_addr)))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_resolve_addr(ctx->cm_id, src, dst, cmd.timeout_ms);
+ ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
+ (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
ucma_put_ctx(ctx);
return ret;
}
@@ -1432,7 +1432,7 @@ static ssize_t ucma_join_ip_multicast(st
join_cmd.response = cmd.response;
join_cmd.uid = cmd.uid;
join_cmd.id = cmd.id;
- join_cmd.addr_size = rdma_addr_size((struct sockaddr *) &cmd.addr);
+ join_cmd.addr_size = rdma_addr_size_in6(&cmd.addr);
if (!join_cmd.addr_size)
return -EINVAL;
@@ -1451,7 +1451,7 @@ static ssize_t ucma_join_multicast(struc
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- if (!rdma_addr_size((struct sockaddr *)&cmd.addr))
+ if (!rdma_addr_size_kss(&cmd.addr))
return -EINVAL;
return ucma_process_join(file, &cmd, out_len);
--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -129,6 +129,8 @@ int rdma_copy_addr(struct rdma_dev_addr
const unsigned char *dst_dev_addr);
int rdma_addr_size(struct sockaddr *addr);
+int rdma_addr_size_in6(struct sockaddr_in6 *addr);
+int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
int rdma_addr_find_smac_by_sgid(union ib_gid *sgid, u8 *smac, u16 *vlan_id);
int rdma_addr_find_l2_eth_by_grh(const union ib_gid *sgid,
Patches currently in stable-queue which might be from roland(a)purestorage.com are
queue-4.14/rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Fix use-after-free access in ucma_close
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ed65a4dc22083e73bac599ded6a262318cad7baf Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Mon, 19 Mar 2018 14:20:15 +0200
Subject: RDMA/ucma: Fix use-after-free access in ucma_close
From: Leon Romanovsky <leonro(a)mellanox.com>
commit ed65a4dc22083e73bac599ded6a262318cad7baf upstream.
The error in ucma_create_id() left ctx in the list of contexts belong
to ucma file descriptor. The attempt to close this file descriptor causes
to use-after-free accesses while iterating over such list.
Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Reported-by: <syzbot+dcfd344365a56fbebd0f(a)syzkaller.appspotmail.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Reviewed-by: Sean Hefty <sean.hefty(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/ucma.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -497,6 +497,9 @@ err1:
mutex_lock(&mut);
idr_remove(&ctx_idr, ctx->id);
mutex_unlock(&mut);
+ mutex_lock(&file->mut);
+ list_del(&ctx->list);
+ mutex_unlock(&file->mut);
kfree(ctx);
return ret;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.14/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.14/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.14/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.14/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.14/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Check that device exists prior to accessing it
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c8d3bcbfc5eab3f01cf373d039af725f3b488813 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Sun, 25 Mar 2018 11:39:05 +0300
Subject: RDMA/ucma: Check that device exists prior to accessing it
From: Leon Romanovsky <leonro(a)mellanox.com>
commit c8d3bcbfc5eab3f01cf373d039af725f3b488813 upstream.
Ensure that device exists prior to accessing its properties.
Reported-by: <syzbot+71655d44855ac3e76366(a)syzkaller.appspotmail.com>
Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/ucma.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -1335,7 +1335,7 @@ static ssize_t ucma_notify(struct ucma_f
{
struct rdma_ucm_notify cmd;
struct ucma_context *ctx;
- int ret;
+ int ret = -EINVAL;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
@@ -1344,7 +1344,9 @@ static ssize_t ucma_notify(struct ucma_f
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_notify(ctx->cm_id, (enum ib_event_type) cmd.event);
+ if (ctx->cm_id->device)
+ ret = rdma_notify(ctx->cm_id, (enum ib_event_type)cmd.event);
+
ucma_put_ctx(ctx);
return ret;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.14/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.14/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.14/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.14/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.14/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
RDMA/rdma_cm: Fix use after free race with process_one_req
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-rdma_cm-fix-use-after-free-race-with-process_one_req.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9137108cc3d64ade13e753108ec611a0daed16a0 Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgg(a)mellanox.com>
Date: Thu, 22 Mar 2018 14:04:23 -0600
Subject: RDMA/rdma_cm: Fix use after free race with process_one_req
From: Jason Gunthorpe <jgg(a)mellanox.com>
commit 9137108cc3d64ade13e753108ec611a0daed16a0 upstream.
process_one_req() can race with rdma_addr_cancel():
CPU0 CPU1
==== ====
process_one_work()
debug_work_deactivate(work);
process_one_req()
rdma_addr_cancel()
mutex_lock(&lock);
set_timeout(&req->work,..);
__queue_work()
debug_work_activate(work);
mutex_unlock(&lock);
mutex_lock(&lock);
[..]
list_del(&req->list);
mutex_unlock(&lock);
[..]
// ODEBUG explodes since the work is still queued.
kfree(req);
Causing ODEBUG to detect the use after free:
ODEBUG: free active (active state 0) object type: work_struct hint: process_one_req+0x0/0x6c0 include/net/dst.h:165
WARNING: CPU: 0 PID: 79 at lib/debugobjects.c:291 debug_print_object+0x166/0x220 lib/debugobjects.c:288
kvm: emulating exchange as write
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 79 Comm: kworker/u4:3 Not tainted 4.16.0-rc6+ #361
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: ib_addr process_one_req
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
__warn+0x1dc/0x200 kernel/panic.c:547
report_bug+0x1f4/0x2b0 lib/bug.c:186
fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
RIP: 0010:debug_print_object+0x166/0x220 lib/debugobjects.c:288
RSP: 0000:ffff8801d966f210 EFLAGS: 00010086
RAX: dffffc0000000008 RBX: 0000000000000003 RCX: ffffffff815acd6e
RDX: 0000000000000000 RSI: 1ffff1003b2cddf2 RDI: 0000000000000000
RBP: ffff8801d966f250 R08: 0000000000000000 R09: 1ffff1003b2cddc8
R10: ffffed003b2cde71 R11: ffffffff86f39a98 R12: 0000000000000001
R13: ffffffff86f15540 R14: ffffffff86408700 R15: ffffffff8147c0a0
__debug_check_no_obj_freed lib/debugobjects.c:745 [inline]
debug_check_no_obj_freed+0x662/0xf1f lib/debugobjects.c:774
kfree+0xc7/0x260 mm/slab.c:3799
process_one_req+0x2e7/0x6c0 drivers/infiniband/core/addr.c:592
process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
worker_thread+0x223/0x1990 kernel/workqueue.c:2247
kthread+0x33c/0x400 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
Fixes: 5fff41e1f89d ("IB/core: Fix race condition in resolving IP to MAC")
Reported-by: <syzbot+3b4acab09b6463472d0a(a)syzkaller.appspotmail.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/addr.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -597,6 +597,15 @@ static void process_one_req(struct work_
list_del(&req->list);
mutex_unlock(&lock);
+ /*
+ * Although the work will normally have been canceled by the
+ * workqueue, it can still be requeued as long as it is on the
+ * req_list, so it could have been requeued before we grabbed &lock.
+ * We need to cancel it after it is removed from req_list to really be
+ * sure it is safe to free.
+ */
+ cancel_delayed_work(&req->work);
+
req->callback(req->status, (struct sockaddr *)&req->src_addr,
req->addr, req->context);
put_client(req->client);
Patches currently in stable-queue which might be from jgg(a)mellanox.com are
queue-4.14/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.14/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.14/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.14/rdma-rdma_cm-fix-use-after-free-race-with-process_one_req.patch
queue-4.14/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.14/rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
queue-4.14/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
xfrm_user: uncoditionally validate esn replay attribute struct
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d97ca5d714a5334aecadadf696875da40f1fbf3e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Mon, 12 Feb 2018 14:42:01 +0100
Subject: xfrm_user: uncoditionally validate esn replay attribute struct
From: Florian Westphal <fw(a)strlen.de>
commit d97ca5d714a5334aecadadf696875da40f1fbf3e upstream.
The sanity test added in ecd7918745234 can be bypassed, validation
only occurs if XFRM_STATE_ESN flag is set, but rest of code doesn't care
and just checks if the attribute itself is present.
So always validate. Alternative is to reject if we have the attribute
without the flag but that would change abi.
Reported-by: syzbot+0ab777c27d2bb7588f73(a)syzkaller.appspotmail.com
Cc: Mathias Krause <minipli(a)googlemail.com>
Fixes: ecd7918745234 ("xfrm_user: ensure user supplied esn replay window is valid")
Fixes: d8647b79c3b7e ("xfrm: Add user interface for esn and big anti-replay windows")
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_user.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -121,22 +121,17 @@ static inline int verify_replay(struct x
struct nlattr *rt = attrs[XFRMA_REPLAY_ESN_VAL];
struct xfrm_replay_state_esn *rs;
- if (p->flags & XFRM_STATE_ESN) {
- if (!rt)
- return -EINVAL;
-
- rs = nla_data(rt);
+ if (!rt)
+ return (p->flags & XFRM_STATE_ESN) ? -EINVAL : 0;
- if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
- return -EINVAL;
+ rs = nla_data(rt);
- if (nla_len(rt) < (int)xfrm_replay_state_esn_len(rs) &&
- nla_len(rt) != sizeof(*rs))
- return -EINVAL;
- }
+ if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
+ return -EINVAL;
- if (!rt)
- return 0;
+ if (nla_len(rt) < (int)xfrm_replay_state_esn_len(rs) &&
+ nla_len(rt) != sizeof(*rs))
+ return -EINVAL;
/* As only ESP and AH support ESN feature. */
if ((p->id.proto != IPPROTO_ESP) && (p->id.proto != IPPROTO_AH))
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.15/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Introduce safer rdma_addr_size() variants
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 84652aefb347297aa08e91e283adf7b18f77c2d5 Mon Sep 17 00:00:00 2001
From: Roland Dreier <roland(a)purestorage.com>
Date: Wed, 28 Mar 2018 11:27:22 -0700
Subject: RDMA/ucma: Introduce safer rdma_addr_size() variants
From: Roland Dreier <roland(a)purestorage.com>
commit 84652aefb347297aa08e91e283adf7b18f77c2d5 upstream.
There are several places in the ucma ABI where userspace can pass in a
sockaddr but set the address family to AF_IB. When that happens,
rdma_addr_size() will return a size bigger than sizeof struct sockaddr_in6,
and the ucma kernel code might end up copying past the end of a buffer
not sized for a struct sockaddr_ib.
Fix this by introducing new variants
int rdma_addr_size_in6(struct sockaddr_in6 *addr);
int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
that are type-safe for the types used in the ucma ABI and return 0 if the
size computed is bigger than the size of the type passed in. We can use
these new variants to check what size userspace has passed in before
copying any addresses.
Reported-by: <syzbot+6800425d54ed3ed8135d(a)syzkaller.appspotmail.com>
Signed-off-by: Roland Dreier <roland(a)purestorage.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/addr.c | 16 ++++++++++++++++
drivers/infiniband/core/ucma.c | 34 +++++++++++++++++-----------------
include/rdma/ib_addr.h | 2 ++
3 files changed, 35 insertions(+), 17 deletions(-)
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -207,6 +207,22 @@ int rdma_addr_size(struct sockaddr *addr
}
EXPORT_SYMBOL(rdma_addr_size);
+int rdma_addr_size_in6(struct sockaddr_in6 *addr)
+{
+ int ret = rdma_addr_size((struct sockaddr *) addr);
+
+ return ret <= sizeof(*addr) ? ret : 0;
+}
+EXPORT_SYMBOL(rdma_addr_size_in6);
+
+int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr)
+{
+ int ret = rdma_addr_size((struct sockaddr *) addr);
+
+ return ret <= sizeof(*addr) ? ret : 0;
+}
+EXPORT_SYMBOL(rdma_addr_size_kss);
+
static struct rdma_addr_client self;
void rdma_addr_register_client(struct rdma_addr_client *client)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -632,6 +632,9 @@ static ssize_t ucma_bind_ip(struct ucma_
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
+ if (!rdma_addr_size_in6(&cmd.addr))
+ return -EINVAL;
+
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
@@ -645,22 +648,21 @@ static ssize_t ucma_bind(struct ucma_fil
int in_len, int out_len)
{
struct rdma_ucm_bind cmd;
- struct sockaddr *addr;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- addr = (struct sockaddr *) &cmd.addr;
- if (cmd.reserved || !cmd.addr_size || (cmd.addr_size != rdma_addr_size(addr)))
+ if (cmd.reserved || !cmd.addr_size ||
+ cmd.addr_size != rdma_addr_size_kss(&cmd.addr))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_bind_addr(ctx->cm_id, addr);
+ ret = rdma_bind_addr(ctx->cm_id, (struct sockaddr *) &cmd.addr);
ucma_put_ctx(ctx);
return ret;
}
@@ -670,23 +672,22 @@ static ssize_t ucma_resolve_ip(struct uc
int in_len, int out_len)
{
struct rdma_ucm_resolve_ip cmd;
- struct sockaddr *src, *dst;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- src = (struct sockaddr *) &cmd.src_addr;
- dst = (struct sockaddr *) &cmd.dst_addr;
- if (!rdma_addr_size(src) || !rdma_addr_size(dst))
+ if (!rdma_addr_size_in6(&cmd.src_addr) ||
+ !rdma_addr_size_in6(&cmd.dst_addr))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_resolve_addr(ctx->cm_id, src, dst, cmd.timeout_ms);
+ ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
+ (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
ucma_put_ctx(ctx);
return ret;
}
@@ -696,24 +697,23 @@ static ssize_t ucma_resolve_addr(struct
int in_len, int out_len)
{
struct rdma_ucm_resolve_addr cmd;
- struct sockaddr *src, *dst;
struct ucma_context *ctx;
int ret;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- src = (struct sockaddr *) &cmd.src_addr;
- dst = (struct sockaddr *) &cmd.dst_addr;
- if (cmd.reserved || (cmd.src_size && (cmd.src_size != rdma_addr_size(src))) ||
- !cmd.dst_size || (cmd.dst_size != rdma_addr_size(dst)))
+ if (cmd.reserved ||
+ (cmd.src_size && (cmd.src_size != rdma_addr_size_kss(&cmd.src_addr))) ||
+ !cmd.dst_size || (cmd.dst_size != rdma_addr_size_kss(&cmd.dst_addr)))
return -EINVAL;
ctx = ucma_get_ctx(file, cmd.id);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_resolve_addr(ctx->cm_id, src, dst, cmd.timeout_ms);
+ ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr,
+ (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms);
ucma_put_ctx(ctx);
return ret;
}
@@ -1432,7 +1432,7 @@ static ssize_t ucma_join_ip_multicast(st
join_cmd.response = cmd.response;
join_cmd.uid = cmd.uid;
join_cmd.id = cmd.id;
- join_cmd.addr_size = rdma_addr_size((struct sockaddr *) &cmd.addr);
+ join_cmd.addr_size = rdma_addr_size_in6(&cmd.addr);
if (!join_cmd.addr_size)
return -EINVAL;
@@ -1451,7 +1451,7 @@ static ssize_t ucma_join_multicast(struc
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- if (!rdma_addr_size((struct sockaddr *)&cmd.addr))
+ if (!rdma_addr_size_kss(&cmd.addr))
return -EINVAL;
return ucma_process_join(file, &cmd, out_len);
--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -130,6 +130,8 @@ void rdma_copy_addr(struct rdma_dev_addr
const unsigned char *dst_dev_addr);
int rdma_addr_size(struct sockaddr *addr);
+int rdma_addr_size_in6(struct sockaddr_in6 *addr);
+int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
int rdma_addr_find_smac_by_sgid(union ib_gid *sgid, u8 *smac, u16 *vlan_id);
int rdma_addr_find_l2_eth_by_grh(const union ib_gid *sgid,
Patches currently in stable-queue which might be from roland(a)purestorage.com are
queue-4.15/rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Fix use-after-free access in ucma_close
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ed65a4dc22083e73bac599ded6a262318cad7baf Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Mon, 19 Mar 2018 14:20:15 +0200
Subject: RDMA/ucma: Fix use-after-free access in ucma_close
From: Leon Romanovsky <leonro(a)mellanox.com>
commit ed65a4dc22083e73bac599ded6a262318cad7baf upstream.
The error in ucma_create_id() left ctx in the list of contexts belong
to ucma file descriptor. The attempt to close this file descriptor causes
to use-after-free accesses while iterating over such list.
Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Reported-by: <syzbot+dcfd344365a56fbebd0f(a)syzkaller.appspotmail.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Reviewed-by: Sean Hefty <sean.hefty(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/ucma.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -497,6 +497,9 @@ err1:
mutex_lock(&mut);
idr_remove(&ctx_idr, ctx->id);
mutex_unlock(&mut);
+ mutex_lock(&file->mut);
+ list_del(&ctx->list);
+ mutex_unlock(&file->mut);
kfree(ctx);
return ret;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.15/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.15/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.15/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.15/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.15/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
RDMA/ucma: Check that device exists prior to accessing it
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c8d3bcbfc5eab3f01cf373d039af725f3b488813 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky <leonro(a)mellanox.com>
Date: Sun, 25 Mar 2018 11:39:05 +0300
Subject: RDMA/ucma: Check that device exists prior to accessing it
From: Leon Romanovsky <leonro(a)mellanox.com>
commit c8d3bcbfc5eab3f01cf373d039af725f3b488813 upstream.
Ensure that device exists prior to accessing its properties.
Reported-by: <syzbot+71655d44855ac3e76366(a)syzkaller.appspotmail.com>
Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/ucma.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -1335,7 +1335,7 @@ static ssize_t ucma_notify(struct ucma_f
{
struct rdma_ucm_notify cmd;
struct ucma_context *ctx;
- int ret;
+ int ret = -EINVAL;
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
@@ -1344,7 +1344,9 @@ static ssize_t ucma_notify(struct ucma_f
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ret = rdma_notify(ctx->cm_id, (enum ib_event_type) cmd.event);
+ if (ctx->cm_id->device)
+ ret = rdma_notify(ctx->cm_id, (enum ib_event_type)cmd.event);
+
ucma_put_ctx(ctx);
return ret;
}
Patches currently in stable-queue which might be from leonro(a)mellanox.com are
queue-4.15/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.15/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.15/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.15/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.15/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
RDMA/rdma_cm: Fix use after free race with process_one_req
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-rdma_cm-fix-use-after-free-race-with-process_one_req.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9137108cc3d64ade13e753108ec611a0daed16a0 Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jgg(a)mellanox.com>
Date: Thu, 22 Mar 2018 14:04:23 -0600
Subject: RDMA/rdma_cm: Fix use after free race with process_one_req
From: Jason Gunthorpe <jgg(a)mellanox.com>
commit 9137108cc3d64ade13e753108ec611a0daed16a0 upstream.
process_one_req() can race with rdma_addr_cancel():
CPU0 CPU1
==== ====
process_one_work()
debug_work_deactivate(work);
process_one_req()
rdma_addr_cancel()
mutex_lock(&lock);
set_timeout(&req->work,..);
__queue_work()
debug_work_activate(work);
mutex_unlock(&lock);
mutex_lock(&lock);
[..]
list_del(&req->list);
mutex_unlock(&lock);
[..]
// ODEBUG explodes since the work is still queued.
kfree(req);
Causing ODEBUG to detect the use after free:
ODEBUG: free active (active state 0) object type: work_struct hint: process_one_req+0x0/0x6c0 include/net/dst.h:165
WARNING: CPU: 0 PID: 79 at lib/debugobjects.c:291 debug_print_object+0x166/0x220 lib/debugobjects.c:288
kvm: emulating exchange as write
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 79 Comm: kworker/u4:3 Not tainted 4.16.0-rc6+ #361
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: ib_addr process_one_req
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
__warn+0x1dc/0x200 kernel/panic.c:547
report_bug+0x1f4/0x2b0 lib/bug.c:186
fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
RIP: 0010:debug_print_object+0x166/0x220 lib/debugobjects.c:288
RSP: 0000:ffff8801d966f210 EFLAGS: 00010086
RAX: dffffc0000000008 RBX: 0000000000000003 RCX: ffffffff815acd6e
RDX: 0000000000000000 RSI: 1ffff1003b2cddf2 RDI: 0000000000000000
RBP: ffff8801d966f250 R08: 0000000000000000 R09: 1ffff1003b2cddc8
R10: ffffed003b2cde71 R11: ffffffff86f39a98 R12: 0000000000000001
R13: ffffffff86f15540 R14: ffffffff86408700 R15: ffffffff8147c0a0
__debug_check_no_obj_freed lib/debugobjects.c:745 [inline]
debug_check_no_obj_freed+0x662/0xf1f lib/debugobjects.c:774
kfree+0xc7/0x260 mm/slab.c:3799
process_one_req+0x2e7/0x6c0 drivers/infiniband/core/addr.c:592
process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
worker_thread+0x223/0x1990 kernel/workqueue.c:2247
kthread+0x33c/0x400 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
Fixes: 5fff41e1f89d ("IB/core: Fix race condition in resolving IP to MAC")
Reported-by: <syzbot+3b4acab09b6463472d0a(a)syzkaller.appspotmail.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/addr.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -598,6 +598,15 @@ static void process_one_req(struct work_
list_del(&req->list);
mutex_unlock(&lock);
+ /*
+ * Although the work will normally have been canceled by the
+ * workqueue, it can still be requeued as long as it is on the
+ * req_list, so it could have been requeued before we grabbed &lock.
+ * We need to cancel it after it is removed from req_list to really be
+ * sure it is safe to free.
+ */
+ cancel_delayed_work(&req->work);
+
req->callback(req->status, (struct sockaddr *)&req->src_addr,
req->addr, req->context);
put_client(req->client);
Patches currently in stable-queue which might be from jgg(a)mellanox.com are
queue-4.15/rdma-ucma-check-af-family-prior-resolving-address.patch
queue-4.15/rdma-ucma-check-that-device-is-connected-prior-to-access-it.patch
queue-4.15/rdma-ucma-fix-use-after-free-access-in-ucma_close.patch
queue-4.15/rdma-rdma_cm-fix-use-after-free-race-with-process_one_req.patch
queue-4.15/rdma-ucma-ensure-that-cm_id-exists-prior-to-access-it.patch
queue-4.15/rdma-ucma-introduce-safer-rdma_addr_size-variants.patch
queue-4.15/rdma-ucma-check-that-device-exists-prior-to-accessing-it.patch
This is a note to let you know that I've just added the patch titled
xfrm_user: uncoditionally validate esn replay attribute struct
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d97ca5d714a5334aecadadf696875da40f1fbf3e Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Mon, 12 Feb 2018 14:42:01 +0100
Subject: xfrm_user: uncoditionally validate esn replay attribute struct
From: Florian Westphal <fw(a)strlen.de>
commit d97ca5d714a5334aecadadf696875da40f1fbf3e upstream.
The sanity test added in ecd7918745234 can be bypassed, validation
only occurs if XFRM_STATE_ESN flag is set, but rest of code doesn't care
and just checks if the attribute itself is present.
So always validate. Alternative is to reject if we have the attribute
without the flag but that would change abi.
Reported-by: syzbot+0ab777c27d2bb7588f73(a)syzkaller.appspotmail.com
Cc: Mathias Krause <minipli(a)googlemail.com>
Fixes: ecd7918745234 ("xfrm_user: ensure user supplied esn replay window is valid")
Fixes: d8647b79c3b7e ("xfrm: Add user interface for esn and big anti-replay windows")
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_user.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -120,22 +120,17 @@ static inline int verify_replay(struct x
struct nlattr *rt = attrs[XFRMA_REPLAY_ESN_VAL];
struct xfrm_replay_state_esn *rs;
- if (p->flags & XFRM_STATE_ESN) {
- if (!rt)
- return -EINVAL;
-
- rs = nla_data(rt);
+ if (!rt)
+ return (p->flags & XFRM_STATE_ESN) ? -EINVAL : 0;
- if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
- return -EINVAL;
+ rs = nla_data(rt);
- if (nla_len(rt) < xfrm_replay_state_esn_len(rs) &&
- nla_len(rt) != sizeof(*rs))
- return -EINVAL;
- }
+ if (rs->bmp_len > XFRMA_REPLAY_ESN_MAX / sizeof(rs->bmp[0]) / 8)
+ return -EINVAL;
- if (!rt)
- return 0;
+ if (nla_len(rt) < xfrm_replay_state_esn_len(rs) &&
+ nla_len(rt) != sizeof(*rs))
+ return -EINVAL;
/* As only ESP and AH support ESN feature. */
if ((p->id.proto != IPPROTO_ESP) && (p->id.proto != IPPROTO_AH))
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-3.18/xfrm_user-uncoditionally-validate-esn-replay-attribute-struct.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: remove redundant self assignment
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-remove-redundant-self-assignment.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8a8b161df5ce06ef5a315899f83978e765be09e8 Mon Sep 17 00:00:00 2001
From: Stefan Agner <stefan(a)agner.ch>
Date: Sun, 16 Apr 2017 20:12:50 -0700
Subject: usb: gadget: remove redundant self assignment
From: Stefan Agner <stefan(a)agner.ch>
commit 8a8b161df5ce06ef5a315899f83978e765be09e8 upstream.
The assignment ret = ret is redundant and can be removed.
Reviewed-by: Krzysztof Opasiak <k.opasiak(a)samsung.com>
Reviewed-by: Peter Chen <peter.chen(a)nxp.com>
Signed-off-by: Stefan Agner <stefan(a)agner.ch>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -139,10 +139,8 @@ int usb_ep_disable(struct usb_ep *ep)
goto out;
ret = ep->ops->disable(ep);
- if (ret) {
- ret = ret;
+ if (ret)
goto out;
- }
ep->enabled = false;
Patches currently in stable-queue which might be from stefan(a)agner.ch are
queue-4.9/usb-gadget-remove-redundant-self-assignment.patch
This is a note to let you know that I've just added the patch titled
nl80211: Fix enum type of variable in nl80211_put_sta_rate()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nl80211-fix-enum-type-of-variable-in-nl80211_put_sta_rate.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From bbf67e450a5dc2a595e1e7a67b4869f1a7f5a338 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Mon, 17 Apr 2017 15:59:52 -0700
Subject: nl80211: Fix enum type of variable in nl80211_put_sta_rate()
From: Matthias Kaehlcke <mka(a)chromium.org>
commit bbf67e450a5dc2a595e1e7a67b4869f1a7f5a338 upstream.
rate_flg is of type 'enum nl80211_attrs', however it is assigned with
'enum nl80211_rate_info' values. Change the type of rate_flg accordingly.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4081,7 +4081,7 @@ static bool nl80211_put_sta_rate(struct
struct nlattr *rate;
u32 bitrate;
u16 bitrate_compat;
- enum nl80211_attrs rate_flg;
+ enum nl80211_rate_info rate_flg;
rate = nla_nest_start(msg, attr);
if (!rate)
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.9/btrfs-remove-extra-parentheses-from-condition-in-copy_items.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/nl80211-fix-enum-type-of-variable-in-nl80211_put_sta_rate.patch
queue-4.9/selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.9/mac80211-ibss-fix-channel-type-enum-in-ieee80211_sta_join_ibss.patch
queue-4.9/cfg80211-fix-array-bounds-warning-in-fragment-copy.patch
queue-4.9/netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
queue-4.9/mac80211-fix-clang-warning-about-constant-operand-in-logical-operation.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
selinux: Remove redundant check for unknown labeling behavior
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 270e8573145a26de924e2dc644596332d400445b Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Fri, 19 May 2017 10:09:32 -0700
Subject: selinux: Remove redundant check for unknown labeling behavior
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 270e8573145a26de924e2dc644596332d400445b upstream.
The check is already performed in ocontext_read() when the policy is
loaded. Removing the array also fixes the following warning when
building with clang:
security/selinux/hooks.c:338:20: error: variable 'labeling_behaviors'
is not needed and will not be emitted
[-Werror,-Wunneeded-internal-declaration]
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Acked-by: Stephen Smalley <sds(a)tycho.nsa.gov>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/hooks.c | 16 ----------------
1 file changed, 16 deletions(-)
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -406,18 +406,6 @@ static void superblock_free_security(str
kfree(sbsec);
}
-/* The file system's label must be initialized prior to use. */
-
-static const char *labeling_behaviors[7] = {
- "uses xattr",
- "uses transition SIDs",
- "uses task SIDs",
- "uses genfs_contexts",
- "not configured for labeling",
- "uses mountpoint labeling",
- "uses native labeling",
-};
-
static inline int inode_doinit(struct inode *inode)
{
return inode_doinit_with_dentry(inode, NULL);
@@ -528,10 +516,6 @@ static int sb_finish_set_opts(struct sup
}
}
- if (sbsec->behavior > ARRAY_SIZE(labeling_behaviors))
- printk(KERN_ERR "SELinux: initialized (dev %s, type %s), unknown behavior\n",
- sb->s_id, sb->s_type->name);
-
sbsec->flags |= SE_SBINITIALIZED;
if (selinux_is_sblabel_mnt(sb))
sbsec->flags |= SBLABEL_MNT;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.9/btrfs-remove-extra-parentheses-from-condition-in-copy_items.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/nl80211-fix-enum-type-of-variable-in-nl80211_put_sta_rate.patch
queue-4.9/selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.9/mac80211-ibss-fix-channel-type-enum-in-ieee80211_sta_join_ibss.patch
queue-4.9/cfg80211-fix-array-bounds-warning-in-fragment-copy.patch
queue-4.9/netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
queue-4.9/mac80211-fix-clang-warning-about-constant-operand-in-logical-operation.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
netfilter: ctnetlink: Make some parameters integer to avoid enum mismatch
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a2b7cbdd2559aff06cebc28a7150f81c307a90d3 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Wed, 19 Apr 2017 11:39:20 -0700
Subject: netfilter: ctnetlink: Make some parameters integer to avoid enum mismatch
From: Matthias Kaehlcke <mka(a)chromium.org>
commit a2b7cbdd2559aff06cebc28a7150f81c307a90d3 upstream.
Not all parameters passed to ctnetlink_parse_tuple() and
ctnetlink_exp_dump_tuple() match the enum type in the signatures of these
functions. Since this is intended change the argument type of to be an
unsigned integer value.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/nf_conntrack_netlink.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1008,9 +1008,8 @@ static const struct nla_policy tuple_nla
static int
ctnetlink_parse_tuple(const struct nlattr * const cda[],
- struct nf_conntrack_tuple *tuple,
- enum ctattr_type type, u_int8_t l3num,
- struct nf_conntrack_zone *zone)
+ struct nf_conntrack_tuple *tuple, u32 type,
+ u_int8_t l3num, struct nf_conntrack_zone *zone)
{
struct nlattr *tb[CTA_TUPLE_MAX+1];
int err;
@@ -2409,7 +2408,7 @@ static struct nfnl_ct_hook ctnetlink_glu
static int ctnetlink_exp_dump_tuple(struct sk_buff *skb,
const struct nf_conntrack_tuple *tuple,
- enum ctattr_expect type)
+ u32 type)
{
struct nlattr *nest_parms;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.9/btrfs-remove-extra-parentheses-from-condition-in-copy_items.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/nl80211-fix-enum-type-of-variable-in-nl80211_put_sta_rate.patch
queue-4.9/selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.9/mac80211-ibss-fix-channel-type-enum-in-ieee80211_sta_join_ibss.patch
queue-4.9/cfg80211-fix-array-bounds-warning-in-fragment-copy.patch
queue-4.9/netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
queue-4.9/mac80211-fix-clang-warning-about-constant-operand-in-logical-operation.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
mm/vmscan.c: fix unsequenced modification and access warning
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mm-vmscan.c-fix-unsequenced-modification-and-access-warning.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f2f43e566a02a3bdde0a65e6a2e88d707c212a29 Mon Sep 17 00:00:00 2001
From: Nick Desaulniers <nick.desaulniers(a)gmail.com>
Date: Thu, 6 Jul 2017 15:36:50 -0700
Subject: mm/vmscan.c: fix unsequenced modification and access warning
From: Nick Desaulniers <nick.desaulniers(a)gmail.com>
commit f2f43e566a02a3bdde0a65e6a2e88d707c212a29 upstream.
Clang and its -Wunsequenced emits a warning
mm/vmscan.c:2961:25: error: unsequenced modification and access to 'gfp_mask' [-Wunsequenced]
.gfp_mask = (gfp_mask = current_gfp_context(gfp_mask)),
^
While it is not clear to me whether the initialization code violates the
specification (6.7.8 par 19 (ISO/IEC 9899) looks like it disagrees) the
code is quite confusing and worth cleaning up anyway. Fix this by
reusing sc.gfp_mask rather than the updated input gfp_mask parameter.
Link: http://lkml.kernel.org/r/20170510154030.10720-1-nick.desaulniers@gmail.com
Signed-off-by: Nick Desaulniers <nick.desaulniers(a)gmail.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
[natechancellor: Adjust context due to abscence of 7dea19f9ee63]
Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/vmscan.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2966,7 +2966,7 @@ unsigned long try_to_free_pages(struct z
unsigned long nr_reclaimed;
struct scan_control sc = {
.nr_to_reclaim = SWAP_CLUSTER_MAX,
- .gfp_mask = (gfp_mask = memalloc_noio_flags(gfp_mask)),
+ .gfp_mask = memalloc_noio_flags(gfp_mask),
.reclaim_idx = gfp_zone(gfp_mask),
.order = order,
.nodemask = nodemask,
@@ -2981,12 +2981,12 @@ unsigned long try_to_free_pages(struct z
* 1 is returned so that the page allocator does not OOM kill at this
* point.
*/
- if (throttle_direct_reclaim(gfp_mask, zonelist, nodemask))
+ if (throttle_direct_reclaim(sc.gfp_mask, zonelist, nodemask))
return 1;
trace_mm_vmscan_direct_reclaim_begin(order,
sc.may_writepage,
- gfp_mask,
+ sc.gfp_mask,
sc.reclaim_idx);
nr_reclaimed = do_try_to_free_pages(zonelist, &sc);
@@ -3749,16 +3749,15 @@ static int __node_reclaim(struct pglist_
const unsigned long nr_pages = 1 << order;
struct task_struct *p = current;
struct reclaim_state reclaim_state;
- int classzone_idx = gfp_zone(gfp_mask);
struct scan_control sc = {
.nr_to_reclaim = max(nr_pages, SWAP_CLUSTER_MAX),
- .gfp_mask = (gfp_mask = memalloc_noio_flags(gfp_mask)),
+ .gfp_mask = memalloc_noio_flags(gfp_mask),
.order = order,
.priority = NODE_RECLAIM_PRIORITY,
.may_writepage = !!(node_reclaim_mode & RECLAIM_WRITE),
.may_unmap = !!(node_reclaim_mode & RECLAIM_UNMAP),
.may_swap = 1,
- .reclaim_idx = classzone_idx,
+ .reclaim_idx = gfp_zone(gfp_mask),
};
cond_resched();
@@ -3768,7 +3767,7 @@ static int __node_reclaim(struct pglist_
* and RECLAIM_UNMAP.
*/
p->flags |= PF_MEMALLOC | PF_SWAPWRITE;
- lockdep_set_current_reclaim_state(gfp_mask);
+ lockdep_set_current_reclaim_state(sc.gfp_mask);
reclaim_state.reclaimed_slab = 0;
p->reclaim_state = &reclaim_state;
Patches currently in stable-queue which might be from nick.desaulniers(a)gmail.com are
queue-4.9/mm-vmscan.c-fix-unsequenced-modification-and-access-warning.patch
queue-4.9/input-mousedev-fix-implicit-conversion-warning.patch
This is a note to let you know that I've just added the patch titled
mac80211: Fix clang warning about constant operand in logical operation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211-fix-clang-warning-about-constant-operand-in-logical-operation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 93f56de259376d7e4fff2b2d104082e1fa66e237 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Thu, 6 Apr 2017 16:31:41 -0700
Subject: mac80211: Fix clang warning about constant operand in logical operation
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 93f56de259376d7e4fff2b2d104082e1fa66e237 upstream.
When clang detects a non-boolean constant in a logical operation it
generates a 'constant-logical-operand' warning. In
ieee80211_try_rate_control_ops_get() the result of strlen(<const str>)
is used in a logical operation, clang resolves the expression to an
(integer) constant at compile time when clang's builtin strlen function
is used.
Change the condition to check for strlen() > 0 to make the constant
operand boolean and thus avoid the warning.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/rate.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -173,9 +173,11 @@ ieee80211_rate_control_ops_get(const cha
/* try default if specific alg requested but not found */
ops = ieee80211_try_rate_control_ops_get(ieee80211_default_rc_algo);
- /* try built-in one if specific alg requested but not found */
- if (!ops && strlen(CONFIG_MAC80211_RC_DEFAULT))
+ /* Note: check for > 0 is intentional to avoid clang warning */
+ if (!ops && (strlen(CONFIG_MAC80211_RC_DEFAULT) > 0))
+ /* try built-in one if specific alg requested but not found */
ops = ieee80211_try_rate_control_ops_get(CONFIG_MAC80211_RC_DEFAULT);
+
kernel_param_unlock(THIS_MODULE);
return ops;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.9/btrfs-remove-extra-parentheses-from-condition-in-copy_items.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/nl80211-fix-enum-type-of-variable-in-nl80211_put_sta_rate.patch
queue-4.9/selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.9/mac80211-ibss-fix-channel-type-enum-in-ieee80211_sta_join_ibss.patch
queue-4.9/cfg80211-fix-array-bounds-warning-in-fragment-copy.patch
queue-4.9/netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
queue-4.9/mac80211-fix-clang-warning-about-constant-operand-in-logical-operation.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
mac80211: ibss: Fix channel type enum in ieee80211_sta_join_ibss()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211-ibss-fix-channel-type-enum-in-ieee80211_sta_join_ibss.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a4ac6f2e53e568a77a2eb3710efd99ca08634c0a Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Mon, 17 Apr 2017 13:59:53 -0700
Subject: mac80211: ibss: Fix channel type enum in ieee80211_sta_join_ibss()
From: Matthias Kaehlcke <mka(a)chromium.org>
commit a4ac6f2e53e568a77a2eb3710efd99ca08634c0a upstream.
cfg80211_chandef_create() expects an 'enum nl80211_channel_type' as
channel type however in ieee80211_sta_join_ibss()
NL80211_CHAN_WIDTH_20_NOHT is passed in two occasions, which is of
the enum type 'nl80211_chan_width'. Change the value to NL80211_CHAN_NO_HT
(20 MHz, non-HT channel) of the channel type enum.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/ibss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -427,7 +427,7 @@ static void ieee80211_sta_join_ibss(stru
case NL80211_CHAN_WIDTH_5:
case NL80211_CHAN_WIDTH_10:
cfg80211_chandef_create(&chandef, cbss->channel,
- NL80211_CHAN_WIDTH_20_NOHT);
+ NL80211_CHAN_NO_HT);
chandef.width = sdata->u.ibss.chandef.width;
break;
case NL80211_CHAN_WIDTH_80:
@@ -439,7 +439,7 @@ static void ieee80211_sta_join_ibss(stru
default:
/* fall back to 20 MHz for unsupported modes */
cfg80211_chandef_create(&chandef, cbss->channel,
- NL80211_CHAN_WIDTH_20_NOHT);
+ NL80211_CHAN_NO_HT);
break;
}
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.9/btrfs-remove-extra-parentheses-from-condition-in-copy_items.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/nl80211-fix-enum-type-of-variable-in-nl80211_put_sta_rate.patch
queue-4.9/selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.9/mac80211-ibss-fix-channel-type-enum-in-ieee80211_sta_join_ibss.patch
queue-4.9/cfg80211-fix-array-bounds-warning-in-fragment-copy.patch
queue-4.9/netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
queue-4.9/mac80211-fix-clang-warning-about-constant-operand-in-logical-operation.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
HID: sony: Use LED_CORE_SUSPENDRESUME
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-sony-use-led_core_suspendresume.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 765a1077c85e5f2efcc43582f80caf43a052e903 Mon Sep 17 00:00:00 2001
From: Frank Praznik <frank.praznik(a)gmail.com>
Date: Wed, 8 Feb 2017 13:58:43 -0500
Subject: HID: sony: Use LED_CORE_SUSPENDRESUME
From: Frank Praznik <frank.praznik(a)gmail.com>
commit 765a1077c85e5f2efcc43582f80caf43a052e903 upstream.
The LED subsystem provides the LED_CORE_SUSPENDRESUME flag to handle
automatically turning off and restoring the state of device LEDs during
suspend/resume. Use this flag instead of saving and restoring the state
locally.
Signed-off-by: Frank Praznik <frank.praznik(a)gmail.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-sony.c | 45 +++++++++++++++------------------------------
1 file changed, 15 insertions(+), 30 deletions(-)
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1056,7 +1056,6 @@ struct sony_sc {
u8 battery_charging;
u8 battery_capacity;
u8 led_state[MAX_LEDS];
- u8 resume_led_state[MAX_LEDS];
u8 led_delay_on[MAX_LEDS];
u8 led_delay_off[MAX_LEDS];
u8 led_count;
@@ -1793,6 +1792,7 @@ static int sony_leds_init(struct sony_sc
led->name = name;
led->brightness = sc->led_state[n];
led->max_brightness = max_brightness[n];
+ led->flags = LED_CORE_SUSPENDRESUME;
led->brightness_get = sony_led_get_brightness;
led->brightness_set = sony_led_set_brightness;
@@ -2509,47 +2509,32 @@ static void sony_remove(struct hid_devic
static int sony_suspend(struct hid_device *hdev, pm_message_t message)
{
- /*
- * On suspend save the current LED state,
- * stop running force-feedback and blank the LEDS.
- */
- if (SONY_LED_SUPPORT || SONY_FF_SUPPORT) {
- struct sony_sc *sc = hid_get_drvdata(hdev);
-
#ifdef CONFIG_SONY_FF
- sc->left = sc->right = 0;
-#endif
- memcpy(sc->resume_led_state, sc->led_state,
- sizeof(sc->resume_led_state));
- memset(sc->led_state, 0, sizeof(sc->led_state));
+ /* On suspend stop any running force-feedback events */
+ if (SONY_FF_SUPPORT) {
+ struct sony_sc *sc = hid_get_drvdata(hdev);
+ sc->left = sc->right = 0;
sony_send_output_report(sc);
}
+#endif
return 0;
}
static int sony_resume(struct hid_device *hdev)
{
- /* Restore the state of controller LEDs on resume */
- if (SONY_LED_SUPPORT) {
- struct sony_sc *sc = hid_get_drvdata(hdev);
-
- memcpy(sc->led_state, sc->resume_led_state,
- sizeof(sc->led_state));
-
- /*
- * The Sixaxis and navigation controllers on USB need to be
- * reinitialized on resume or they won't behave properly.
- */
- if ((sc->quirks & SIXAXIS_CONTROLLER_USB) ||
- (sc->quirks & NAVIGATION_CONTROLLER_USB)) {
- sixaxis_set_operational_usb(sc->hdev);
- sc->defer_initialization = 1;
- }
+ struct sony_sc *sc = hid_get_drvdata(hdev);
- sony_set_leds(sc);
+ /*
+ * The Sixaxis and navigation controllers on USB need to be
+ * reinitialized on resume or they won't behave properly.
+ */
+ if ((sc->quirks & SIXAXIS_CONTROLLER_USB) ||
+ (sc->quirks & NAVIGATION_CONTROLLER_USB)) {
+ sixaxis_set_operational_usb(sc->hdev);
+ sc->defer_initialization = 1;
}
return 0;
Patches currently in stable-queue which might be from frank.praznik(a)gmail.com are
queue-4.9/hid-sony-use-led_core_suspendresume.patch
This is a note to let you know that I've just added the patch titled
cfg80211: Fix array-bounds warning in fragment copy
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
cfg80211-fix-array-bounds-warning-in-fragment-copy.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From aa1702dd162f420bf85ecef0c77686ef0dbc1496 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Thu, 13 Apr 2017 10:05:04 -0700
Subject: cfg80211: Fix array-bounds warning in fragment copy
From: Matthias Kaehlcke <mka(a)chromium.org>
commit aa1702dd162f420bf85ecef0c77686ef0dbc1496 upstream.
__ieee80211_amsdu_copy_frag intentionally initializes a pointer to
array[-1] to increment it later to valid values. clang rightfully
generates an array-bounds warning on the initialization statement.
Initialize the pointer to array[0] and change the algorithm from
increment before to increment after consume.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/wireless/util.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -663,7 +663,7 @@ __ieee80211_amsdu_copy_frag(struct sk_bu
int offset, int len)
{
struct skb_shared_info *sh = skb_shinfo(skb);
- const skb_frag_t *frag = &sh->frags[-1];
+ const skb_frag_t *frag = &sh->frags[0];
struct page *frag_page;
void *frag_ptr;
int frag_len, frag_size;
@@ -676,10 +676,10 @@ __ieee80211_amsdu_copy_frag(struct sk_bu
while (offset >= frag_size) {
offset -= frag_size;
- frag++;
frag_page = skb_frag_page(frag);
frag_ptr = skb_frag_address(frag);
frag_size = skb_frag_size(frag);
+ frag++;
}
frag_ptr += offset;
@@ -691,12 +691,12 @@ __ieee80211_amsdu_copy_frag(struct sk_bu
len -= cur_len;
while (len > 0) {
- frag++;
frag_len = skb_frag_size(frag);
cur_len = min(len, frag_len);
__frame_add_frag(frame, skb_frag_page(frag),
skb_frag_address(frag), cur_len, frag_len);
len -= cur_len;
+ frag++;
}
}
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.9/btrfs-remove-extra-parentheses-from-condition-in-copy_items.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/nl80211-fix-enum-type-of-variable-in-nl80211_put_sta_rate.patch
queue-4.9/selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.9/mac80211-ibss-fix-channel-type-enum-in-ieee80211_sta_join_ibss.patch
queue-4.9/cfg80211-fix-array-bounds-warning-in-fragment-copy.patch
queue-4.9/netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
queue-4.9/mac80211-fix-clang-warning-about-constant-operand-in-logical-operation.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
btrfs: Remove extra parentheses from condition in copy_items()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-remove-extra-parentheses-from-condition-in-copy_items.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0dde10bed2c44a4024eb446cc72fe4e0cb97ec06 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Thu, 27 Jul 2017 14:30:23 -0700
Subject: btrfs: Remove extra parentheses from condition in copy_items()
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 0dde10bed2c44a4024eb446cc72fe4e0cb97ec06 upstream.
There is no need for the extra pair of parentheses, remove it. This
fixes the following warning when building with clang:
fs/btrfs/tree-log.c:3694:10: warning: equality comparison with extraneous
parentheses [-Wparentheses-equality]
if ((i == (nr - 1)))
~~^~~~~~~~~~~
Also remove the unnecessary parentheses around the substraction.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/tree-log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3664,7 +3664,7 @@ static noinline int copy_items(struct bt
src_offset = btrfs_item_ptr_offset(src, start_slot + i);
- if ((i == (nr - 1)))
+ if (i == nr - 1)
last_key = ins_keys[i];
if (ins_keys[i].type == BTRFS_INODE_ITEM_KEY) {
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.9/btrfs-remove-extra-parentheses-from-condition-in-copy_items.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/nl80211-fix-enum-type-of-variable-in-nl80211_put_sta_rate.patch
queue-4.9/selinux-remove-redundant-check-for-unknown-labeling-behavior.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.9/mac80211-ibss-fix-channel-type-enum-in-ieee80211_sta_join_ibss.patch
queue-4.9/cfg80211-fix-array-bounds-warning-in-fragment-copy.patch
queue-4.9/netfilter-ctnetlink-make-some-parameters-integer-to-avoid-enum-mismatch.patch
queue-4.9/mac80211-fix-clang-warning-about-constant-operand-in-logical-operation.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
arm64: avoid overflow in VA_START and PAGE_OFFSET
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-avoid-overflow-in-va_start-and-page_offset.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 82cd588052815eb4146f9f7c5347ca5e32c56360 Mon Sep 17 00:00:00 2001
From: Nick Desaulniers <ndesaulniers(a)google.com>
Date: Thu, 3 Aug 2017 11:03:58 -0700
Subject: arm64: avoid overflow in VA_START and PAGE_OFFSET
From: Nick Desaulniers <ndesaulniers(a)google.com>
commit 82cd588052815eb4146f9f7c5347ca5e32c56360 upstream.
The bitmask used to define these values produces overflow, as seen by
this compiler warning:
arch/arm64/kernel/head.S:47:8: warning:
integer overflow in preprocessor expression
#elif (PAGE_OFFSET & 0x1fffff) != 0
^~~~~~~~~~~
arch/arm64/include/asm/memory.h:52:46: note:
expanded from macro 'PAGE_OFFSET'
#define PAGE_OFFSET (UL(0xffffffffffffffff) << (VA_BITS -
1))
~~~~~~~~~~~~~~~~~~ ^
It would be preferrable to use GENMASK_ULL() instead, but it's not set
up to be used from assembly (the UL() macro token pastes UL suffixes
when not included in assembly sources).
Suggested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Suggested-by: Yury Norov <ynorov(a)caviumnetworks.com>
Suggested-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/memory.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -64,8 +64,10 @@
* TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
*/
#define VA_BITS (CONFIG_ARM64_VA_BITS)
-#define VA_START (UL(0xffffffffffffffff) << VA_BITS)
-#define PAGE_OFFSET (UL(0xffffffffffffffff) << (VA_BITS - 1))
+#define VA_START (UL(0xffffffffffffffff) - \
+ (UL(1) << VA_BITS) + 1)
+#define PAGE_OFFSET (UL(0xffffffffffffffff) - \
+ (UL(1) << (VA_BITS - 1)) + 1)
#define KIMAGE_VADDR (MODULES_END)
#define MODULES_END (MODULES_VADDR + MODULES_VSIZE)
#define MODULES_VADDR (VA_START + KASAN_SHADOW_SIZE)
Patches currently in stable-queue which might be from ndesaulniers(a)google.com are
queue-4.9/arm64-avoid-overflow-in-va_start-and-page_offset.patch
queue-4.9/netfilter-nf_nat_h323-fix-logical-not-parentheses-warning.patch
Hi Greg,
Please apply the following commits to both 4.4 and 4.9:
9280cdd6fe5b ("fs: compat: Remove warning from COMPATIBLE_IOCTL")
342e91578eb6 ("selinux: Remove unnecessary check of array base in selinux_set_mapping()")
f7e30f01a9e2 ("cpumask: Add helper cpumask_available()")
d170fe7dd992 ("genirq: Use cpumask_available() for check of cpumask variable")
7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp")
60b0a8c3d248 ("frv: declare jiffies to be located in the .data section")
eee6ebbac18a ("netfilter: nf_nat_h323: fix logical-not-parentheses warning")
dae1a432ab1f ("Input: mousedev - fix implicit conversion warning")
e36215d87f30 ("dm ioctl: remove double parentheses")
76dc52684d0f ("PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant")
Please apply the following commits to only 4.4:
c877ef8ae7b8 ("writeback: fix the wrong congested state variable definition")
452889788591 ("ACPI, PCI, irq: remove redundant check for null string pointer")
db0a6fb5d97a ("audit: add tty field to LOGIN event")
Please apply the following commits to only 4.9:
270e8573145a ("selinux: Remove redundant check for unknown labeling behavior")
82cd58805281 ("arm64: avoid overflow in VA_START and PAGE_OFFSET")
0dde10bed2c4 ("btrfs: Remove extra parentheses from condition in copy_items()")
a4ac6f2e53e5 ("mac80211: ibss: Fix channel type enum in ieee80211_sta_join_ibss()")
93f56de25937 ("mac80211: Fix clang warning about constant operand in logical operation")
a2b7cbdd2559 ("netfilter: ctnetlink: Make some parameters integer to avoid enum mismatch")
765a1077c85e ("HID: sony: Use LED_CORE_SUSPENDRESUME")
aa1702dd162f ("cfg80211: Fix array-bounds warning in fragment copy")
bbf67e450a5d ("nl80211: Fix enum type of variable in nl80211_put_sta_rate()")
1f3d62090d3b ("xgene_enet: remove bogus forward declarations")
8a8b161df5ce ("usb: gadget: remove redundant self assignment")
I have verified these all pick clean. I will send separate patches for
the fixes that did not. I have verified everything builds properly with
both GCC and Clang on arm and arm64.
Thanks!
Nathan
This is a note to let you know that I've just added the patch titled
jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7c30f352c852bae2715ad65ac4a38ca9af7d7696 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Mon, 8 May 2017 15:55:05 -0700
Subject: jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 7c30f352c852bae2715ad65ac4a38ca9af7d7696 upstream.
jiffies_64 is defined in kernel/time/timer.c with
____cacheline_aligned_in_smp, however this macro is not part of the
declaration of jiffies and jiffies_64 in jiffies.h.
As a result clang generates the following warning:
kernel/time/timer.c:57:26: error: section does not match previous declaration [-Werror,-Wsection]
__visible u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
^
include/linux/cache.h:39:36: note: expanded from macro '__cacheline_aligned_in_smp'
^
include/linux/cache.h:34:4: note: expanded from macro '__cacheline_aligned'
__section__(".data..cacheline_aligned")))
^
include/linux/jiffies.h:77:12: note: previous attribute is here
extern u64 __jiffy_data jiffies_64;
^
include/linux/jiffies.h:70:38: note: expanded from macro '__jiffy_data'
Link: http://lkml.kernel.org/r/20170403190200.70273-1-mka@chromium.org
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Cc: "Jason A . Donenfeld" <Jason(a)zx2c4.com>
Cc: Grant Grundler <grundler(a)chromium.org>
Cc: Michael Davidson <md(a)google.com>
Cc: Greg Hackmann <ghackmann(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/jiffies.h | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -1,6 +1,7 @@
#ifndef _LINUX_JIFFIES_H
#define _LINUX_JIFFIES_H
+#include <linux/cache.h>
#include <linux/math64.h>
#include <linux/kernel.h>
#include <linux/types.h>
@@ -63,19 +64,13 @@ extern int register_refined_jiffies(long
/* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
#define TICK_USEC ((1000000UL + USER_HZ/2) / USER_HZ)
-/* some arch's have a small-data section that can be accessed register-relative
- * but that can only take up to, say, 4-byte variables. jiffies being part of
- * an 8-byte variable may not be correctly accessed unless we force the issue
- */
-#define __jiffy_data __attribute__((section(".data")))
-
/*
* The 64-bit value is not atomic - you MUST NOT read it
* without sampling the sequence number in jiffies_lock.
* get_jiffies_64() will do this for you as appropriate.
*/
-extern u64 __jiffy_data jiffies_64;
-extern unsigned long volatile __jiffy_data jiffies;
+extern u64 __cacheline_aligned_in_smp jiffies_64;
+extern unsigned long volatile __cacheline_aligned_in_smp jiffies;
#if (BITS_PER_LONG < 64)
u64 get_jiffies_64(void);
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
frv: declare jiffies to be located in the .data section
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
frv-declare-jiffies-to-be-located-in-the-.data-section.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 60b0a8c3d2480f3b57282b47b7cae7ee71c48635 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Fri, 2 Jun 2017 14:46:16 -0700
Subject: frv: declare jiffies to be located in the .data section
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 60b0a8c3d2480f3b57282b47b7cae7ee71c48635 upstream.
Commit 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with
____cacheline_aligned_in_smp") removed a section specification from the
jiffies declaration that caused conflicts on some platforms.
Unfortunately this change broke the build for frv:
kernel/built-in.o: In function `__do_softirq': (.text+0x6460): relocation truncated to fit: R_FRV_GPREL12 against symbol
`jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `__do_softirq': (.text+0x6574): relocation truncated to fit: R_FRV_GPREL12 against symbol
`jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `pwq_activate_delayed_work': workqueue.c:(.text+0x15b9c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
...
Add __jiffy_arch_data to the declaration of jiffies and use it on frv to
include the section specification. For all other platforms
__jiffy_arch_data (currently) has no effect.
Fixes: 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp")
Link: http://lkml.kernel.org/r/20170516221333.177280-1-mka@chromium.org
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Tested-by: Guenter Roeck <linux(a)roeck-us.net>
Reviewed-by: David Howells <dhowells(a)redhat.com>
Cc: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/frv/include/asm/timex.h | 6 ++++++
include/linux/jiffies.h | 6 +++++-
2 files changed, 11 insertions(+), 1 deletion(-)
--- a/arch/frv/include/asm/timex.h
+++ b/arch/frv/include/asm/timex.h
@@ -16,5 +16,11 @@ static inline cycles_t get_cycles(void)
#define vxtime_lock() do {} while (0)
#define vxtime_unlock() do {} while (0)
+/* This attribute is used in include/linux/jiffies.h alongside with
+ * __cacheline_aligned_in_smp. It is assumed that __cacheline_aligned_in_smp
+ * for frv does not contain another section specification.
+ */
+#define __jiffy_arch_data __attribute__((__section__(".data")))
+
#endif
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -64,13 +64,17 @@ extern int register_refined_jiffies(long
/* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
#define TICK_USEC ((1000000UL + USER_HZ/2) / USER_HZ)
+#ifndef __jiffy_arch_data
+#define __jiffy_arch_data
+#endif
+
/*
* The 64-bit value is not atomic - you MUST NOT read it
* without sampling the sequence number in jiffies_lock.
* get_jiffies_64() will do this for you as appropriate.
*/
extern u64 __cacheline_aligned_in_smp jiffies_64;
-extern unsigned long volatile __cacheline_aligned_in_smp jiffies;
+extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies;
#if (BITS_PER_LONG < 64)
u64 get_jiffies_64(void);
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7c30f352c852bae2715ad65ac4a38ca9af7d7696 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Mon, 8 May 2017 15:55:05 -0700
Subject: jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 7c30f352c852bae2715ad65ac4a38ca9af7d7696 upstream.
jiffies_64 is defined in kernel/time/timer.c with
____cacheline_aligned_in_smp, however this macro is not part of the
declaration of jiffies and jiffies_64 in jiffies.h.
As a result clang generates the following warning:
kernel/time/timer.c:57:26: error: section does not match previous declaration [-Werror,-Wsection]
__visible u64 jiffies_64 __cacheline_aligned_in_smp = INITIAL_JIFFIES;
^
include/linux/cache.h:39:36: note: expanded from macro '__cacheline_aligned_in_smp'
^
include/linux/cache.h:34:4: note: expanded from macro '__cacheline_aligned'
__section__(".data..cacheline_aligned")))
^
include/linux/jiffies.h:77:12: note: previous attribute is here
extern u64 __jiffy_data jiffies_64;
^
include/linux/jiffies.h:70:38: note: expanded from macro '__jiffy_data'
Link: http://lkml.kernel.org/r/20170403190200.70273-1-mka@chromium.org
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Cc: "Jason A . Donenfeld" <Jason(a)zx2c4.com>
Cc: Grant Grundler <grundler(a)chromium.org>
Cc: Michael Davidson <md(a)google.com>
Cc: Greg Hackmann <ghackmann(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/jiffies.h | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -1,6 +1,7 @@
#ifndef _LINUX_JIFFIES_H
#define _LINUX_JIFFIES_H
+#include <linux/cache.h>
#include <linux/math64.h>
#include <linux/kernel.h>
#include <linux/types.h>
@@ -63,19 +64,13 @@ extern int register_refined_jiffies(long
/* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
#define TICK_USEC ((1000000UL + USER_HZ/2) / USER_HZ)
-/* some arch's have a small-data section that can be accessed register-relative
- * but that can only take up to, say, 4-byte variables. jiffies being part of
- * an 8-byte variable may not be correctly accessed unless we force the issue
- */
-#define __jiffy_data __attribute__((section(".data")))
-
/*
* The 64-bit value is not atomic - you MUST NOT read it
* without sampling the sequence number in jiffies_lock.
* get_jiffies_64() will do this for you as appropriate.
*/
-extern u64 __jiffy_data jiffies_64;
-extern unsigned long volatile __jiffy_data jiffies;
+extern u64 __cacheline_aligned_in_smp jiffies_64;
+extern unsigned long volatile __cacheline_aligned_in_smp jiffies;
#if (BITS_PER_LONG < 64)
u64 get_jiffies_64(void);
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/dm-ioctl-remove-double-parentheses.patch
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.4/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.4/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.4/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
frv: declare jiffies to be located in the .data section
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
frv-declare-jiffies-to-be-located-in-the-.data-section.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 60b0a8c3d2480f3b57282b47b7cae7ee71c48635 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Fri, 2 Jun 2017 14:46:16 -0700
Subject: frv: declare jiffies to be located in the .data section
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 60b0a8c3d2480f3b57282b47b7cae7ee71c48635 upstream.
Commit 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with
____cacheline_aligned_in_smp") removed a section specification from the
jiffies declaration that caused conflicts on some platforms.
Unfortunately this change broke the build for frv:
kernel/built-in.o: In function `__do_softirq': (.text+0x6460): relocation truncated to fit: R_FRV_GPREL12 against symbol
`jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `__do_softirq': (.text+0x6574): relocation truncated to fit: R_FRV_GPREL12 against symbol
`jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `pwq_activate_delayed_work': workqueue.c:(.text+0x15b9c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
...
Add __jiffy_arch_data to the declaration of jiffies and use it on frv to
include the section specification. For all other platforms
__jiffy_arch_data (currently) has no effect.
Fixes: 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp")
Link: http://lkml.kernel.org/r/20170516221333.177280-1-mka@chromium.org
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Tested-by: Guenter Roeck <linux(a)roeck-us.net>
Reviewed-by: David Howells <dhowells(a)redhat.com>
Cc: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/frv/include/asm/timex.h | 6 ++++++
include/linux/jiffies.h | 6 +++++-
2 files changed, 11 insertions(+), 1 deletion(-)
--- a/arch/frv/include/asm/timex.h
+++ b/arch/frv/include/asm/timex.h
@@ -16,5 +16,11 @@ static inline cycles_t get_cycles(void)
#define vxtime_lock() do {} while (0)
#define vxtime_unlock() do {} while (0)
+/* This attribute is used in include/linux/jiffies.h alongside with
+ * __cacheline_aligned_in_smp. It is assumed that __cacheline_aligned_in_smp
+ * for frv does not contain another section specification.
+ */
+#define __jiffy_arch_data __attribute__((__section__(".data")))
+
#endif
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -64,13 +64,17 @@ extern int register_refined_jiffies(long
/* TICK_USEC is the time between ticks in usec assuming fake USER_HZ */
#define TICK_USEC ((1000000UL + USER_HZ/2) / USER_HZ)
+#ifndef __jiffy_arch_data
+#define __jiffy_arch_data
+#endif
+
/*
* The 64-bit value is not atomic - you MUST NOT read it
* without sampling the sequence number in jiffies_lock.
* get_jiffies_64() will do this for you as appropriate.
*/
extern u64 __cacheline_aligned_in_smp jiffies_64;
-extern unsigned long volatile __cacheline_aligned_in_smp jiffies;
+extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies;
#if (BITS_PER_LONG < 64)
u64 get_jiffies_64(void);
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/dm-ioctl-remove-double-parentheses.patch
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/jiffies.h-declare-jiffies-and-jiffies_64-with-____cacheline_aligned_in_smp.patch
queue-4.4/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.4/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.4/frv-declare-jiffies-to-be-located-in-the-.data-section.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
selinux: Remove unnecessary check of array base in selinux_set_mapping()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 342e91578eb6909529bc7095964cd44b9c057c4e Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Thu, 16 Mar 2017 15:26:52 -0700
Subject: selinux: Remove unnecessary check of array base in selinux_set_mapping()
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 342e91578eb6909529bc7095964cd44b9c057c4e upstream.
'perms' will never be NULL since it isn't a plain pointer but an array
of u32 values.
This fixes the following warning when building with clang:
security/selinux/ss/services.c:158:16: error: address of array
'p_in->perms' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
while (p_in->perms && p_in->perms[k]) {
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -155,7 +155,7 @@ static int selinux_set_mapping(struct po
}
k = 0;
- while (p_in->perms && p_in->perms[k]) {
+ while (p_in->perms[k]) {
/* An empty permission string skips ahead */
if (!*p_in->perms[k]) {
k++;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-make-pci_rom_address_mask-a-32-bit-constant.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 76dc52684d0f72971d9f6cc7d5ae198061b715bd Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Fri, 14 Apr 2017 13:38:02 -0700
Subject: PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 76dc52684d0f72971d9f6cc7d5ae198061b715bd upstream.
A 64-bit value is not needed since a PCI ROM address consists in 32 bits.
This fixes a clang warning about "implicit conversion from 'unsigned long'
to 'u32'".
Also remove now unnecessary casts to u32 from __pci_read_base() and
pci_std_update_resource().
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/probe.c | 2 +-
drivers/pci/setup-res.c | 2 +-
include/uapi/linux/pci_regs.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -231,7 +231,7 @@ int __pci_read_base(struct pci_dev *dev,
res->flags |= IORESOURCE_ROM_ENABLE;
l64 = l & PCI_ROM_ADDRESS_MASK;
sz64 = sz & PCI_ROM_ADDRESS_MASK;
- mask64 = (u32)PCI_ROM_ADDRESS_MASK;
+ mask64 = PCI_ROM_ADDRESS_MASK;
}
if (res->flags & IORESOURCE_MEM_64) {
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -63,7 +63,7 @@ static void pci_std_update_resource(stru
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else if (resno == PCI_ROM_RESOURCE) {
- mask = (u32)PCI_ROM_ADDRESS_MASK;
+ mask = PCI_ROM_ADDRESS_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -106,7 +106,7 @@
#define PCI_SUBSYSTEM_ID 0x2e
#define PCI_ROM_ADDRESS 0x30 /* Bits 31..11 are address, 10..1 reserved */
#define PCI_ROM_ADDRESS_ENABLE 0x01
-#define PCI_ROM_ADDRESS_MASK (~0x7ffUL)
+#define PCI_ROM_ADDRESS_MASK (~0x7ffU)
#define PCI_CAPABILITY_LIST 0x34 /* Offset of first capability list entry */
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
genirq: Use cpumask_available() for check of cpumask variable
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d170fe7dd992b313d4851ae5ab77ee7a51ed8c72 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Wed, 12 Apr 2017 11:20:30 -0700
Subject: genirq: Use cpumask_available() for check of cpumask variable
From: Matthias Kaehlcke <mka(a)chromium.org>
commit d170fe7dd992b313d4851ae5ab77ee7a51ed8c72 upstream.
This fixes the following clang warning when CONFIG_CPUMASK_OFFSTACK=n:
kernel/irq/manage.c:839:28: error: address of array
'desc->irq_common_data.affinity' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Grant Grundler <grundler(a)chromium.org>
Cc: Rusty Russell <rusty(a)rustcorp.com.au>
Cc: Greg Hackmann <ghackmann(a)google.com>
Cc: Michael Davidson <md(a)google.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Link: http://lkml.kernel.org/r/20170412182030.83657-2-mka@chromium.org
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/irq/manage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -850,7 +850,7 @@ irq_thread_check_affinity(struct irq_des
* This code is triggered unconditionally. Check the affinity
* mask pointer. For CPU_MASK_OFFSTACK=n this is optimized out.
*/
- if (desc->irq_common_data.affinity)
+ if (cpumask_available(desc->irq_common_data.affinity))
cpumask_copy(mask, desc->irq_common_data.affinity);
else
valid = false;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
fs: compat: Remove warning from COMPATIBLE_IOCTL
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fs-compat-remove-warning-from-compatible_ioctl.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9280cdd6fe5b8287a726d24cc1d558b96c8491d7 Mon Sep 17 00:00:00 2001
From: Mark Charlebois <charlebm(a)gmail.com>
Date: Fri, 28 Apr 2017 15:15:12 -0700
Subject: fs: compat: Remove warning from COMPATIBLE_IOCTL
From: Mark Charlebois <charlebm(a)gmail.com>
commit 9280cdd6fe5b8287a726d24cc1d558b96c8491d7 upstream.
cmd in COMPATIBLE_IOCTL is always a u32, so cast it so there isn't a
warning about an overflow in XFORM.
From: Mark Charlebois <charlebm(a)gmail.com>
Signed-off-by: Mark Charlebois <charlebm(a)gmail.com>
Signed-off-by: Behan Webster <behanw(a)converseincode.com>
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Acked-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/compat_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -833,7 +833,7 @@ static int compat_ioctl_preallocate(stru
*/
#define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0xffffffff)
-#define COMPATIBLE_IOCTL(cmd) XFORM(cmd),
+#define COMPATIBLE_IOCTL(cmd) XFORM((u32)cmd),
/* ioctl should not be warned about even if it's not implemented.
Valid reasons to use this:
- It is implemented with ->compat_ioctl on some device, but programs
Patches currently in stable-queue which might be from charlebm(a)gmail.com are
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
This is a note to let you know that I've just added the patch titled
dm ioctl: remove double parentheses
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dm-ioctl-remove-double-parentheses.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e36215d87f301f9567c8c99fd34e6c3521a94ddf Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Mon, 17 Apr 2017 11:05:03 -0700
Subject: dm ioctl: remove double parentheses
From: Matthias Kaehlcke <mka(a)chromium.org>
commit e36215d87f301f9567c8c99fd34e6c3521a94ddf upstream.
The extra pair of parantheses is not needed and causes clang to generate
warnings about the DM_DEV_CREATE_CMD comparison in validate_params().
Also remove another double parentheses that doesn't cause a warning.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm-ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1777,12 +1777,12 @@ static int validate_params(uint cmd, str
cmd == DM_LIST_VERSIONS_CMD)
return 0;
- if ((cmd == DM_DEV_CREATE_CMD)) {
+ if (cmd == DM_DEV_CREATE_CMD) {
if (!*param->name) {
DMWARN("name not supplied when creating device");
return -EINVAL;
}
- } else if ((*param->uuid && *param->name)) {
+ } else if (*param->uuid && *param->name) {
DMWARN("only supply one of name or uuid, cmd(%u)", cmd);
return -EINVAL;
}
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
cpumask: Add helper cpumask_available()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
cpumask-add-helper-cpumask_available.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f7e30f01a9e221067bb4b579e3cfc25cd2617467 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Wed, 12 Apr 2017 11:20:29 -0700
Subject: cpumask: Add helper cpumask_available()
From: Matthias Kaehlcke <mka(a)chromium.org>
commit f7e30f01a9e221067bb4b579e3cfc25cd2617467 upstream.
With CONFIG_CPUMASK_OFFSTACK=y cpumask_var_t is a struct cpumask
pointer, otherwise a struct cpumask array with a single element.
Some code dealing with cpumasks needs to validate that a cpumask_var_t
is not a NULL pointer when CONFIG_CPUMASK_OFFSTACK=y. This is typically
done by performing the check always, regardless of the underlying type
of cpumask_var_t. This works in both cases, however clang raises a
warning like this when CONFIG_CPUMASK_OFFSTACK=n:
kernel/irq/manage.c:839:28: error: address of array
'desc->irq_common_data.affinity' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
Add the inline helper cpumask_available() which only performs the
pointer check if CONFIG_CPUMASK_OFFSTACK=y.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Grant Grundler <grundler(a)chromium.org>
Cc: Rusty Russell <rusty(a)rustcorp.com.au>
Cc: Greg Hackmann <ghackmann(a)google.com>
Cc: Michael Davidson <md(a)google.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Link: http://lkml.kernel.org/r/20170412182030.83657-1-mka@chromium.org
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/cpumask.h | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -680,6 +680,11 @@ void alloc_bootmem_cpumask_var(cpumask_v
void free_cpumask_var(cpumask_var_t mask);
void free_bootmem_cpumask_var(cpumask_var_t mask);
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+ return mask != NULL;
+}
+
#else
typedef struct cpumask cpumask_var_t[1];
@@ -720,6 +725,11 @@ static inline void free_cpumask_var(cpum
static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
{
}
+
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+ return true;
+}
#endif /* CONFIG_CPUMASK_OFFSTACK */
/* It's common to want to use cpu_all_mask in struct member initializers,
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.9/dm-ioctl-remove-double-parentheses.patch
queue-4.9/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.9/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.9/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.9/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.9/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
selinux: Remove unnecessary check of array base in selinux_set_mapping()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 342e91578eb6909529bc7095964cd44b9c057c4e Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Thu, 16 Mar 2017 15:26:52 -0700
Subject: selinux: Remove unnecessary check of array base in selinux_set_mapping()
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 342e91578eb6909529bc7095964cd44b9c057c4e upstream.
'perms' will never be NULL since it isn't a plain pointer but an array
of u32 values.
This fixes the following warning when building with clang:
security/selinux/ss/services.c:158:16: error: address of array
'p_in->perms' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
while (p_in->perms && p_in->perms[k]) {
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -155,7 +155,7 @@ static int selinux_set_mapping(struct po
}
k = 0;
- while (p_in->perms && p_in->perms[k]) {
+ while (p_in->perms[k]) {
/* An empty permission string skips ahead */
if (!*p_in->perms[k]) {
k++;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/dm-ioctl-remove-double-parentheses.patch
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.4/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-make-pci_rom_address_mask-a-32-bit-constant.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 76dc52684d0f72971d9f6cc7d5ae198061b715bd Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Fri, 14 Apr 2017 13:38:02 -0700
Subject: PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant
From: Matthias Kaehlcke <mka(a)chromium.org>
commit 76dc52684d0f72971d9f6cc7d5ae198061b715bd upstream.
A 64-bit value is not needed since a PCI ROM address consists in 32 bits.
This fixes a clang warning about "implicit conversion from 'unsigned long'
to 'u32'".
Also remove now unnecessary casts to u32 from __pci_read_base() and
pci_std_update_resource().
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/probe.c | 2 +-
drivers/pci/setup-res.c | 2 +-
include/uapi/linux/pci_regs.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -230,7 +230,7 @@ int __pci_read_base(struct pci_dev *dev,
res->flags |= IORESOURCE_ROM_ENABLE;
l64 = l & PCI_ROM_ADDRESS_MASK;
sz64 = sz & PCI_ROM_ADDRESS_MASK;
- mask64 = (u32)PCI_ROM_ADDRESS_MASK;
+ mask64 = PCI_ROM_ADDRESS_MASK;
}
if (res->flags & IORESOURCE_MEM_64) {
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -63,7 +63,7 @@ static void pci_std_update_resource(stru
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else if (resno == PCI_ROM_RESOURCE) {
- mask = (u32)PCI_ROM_ADDRESS_MASK;
+ mask = PCI_ROM_ADDRESS_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -106,7 +106,7 @@
#define PCI_SUBSYSTEM_ID 0x2e
#define PCI_ROM_ADDRESS 0x30 /* Bits 31..11 are address, 10..1 reserved */
#define PCI_ROM_ADDRESS_ENABLE 0x01
-#define PCI_ROM_ADDRESS_MASK (~0x7ffUL)
+#define PCI_ROM_ADDRESS_MASK (~0x7ffU)
#define PCI_CAPABILITY_LIST 0x34 /* Offset of first capability list entry */
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/dm-ioctl-remove-double-parentheses.patch
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.4/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
genirq: Use cpumask_available() for check of cpumask variable
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d170fe7dd992b313d4851ae5ab77ee7a51ed8c72 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Wed, 12 Apr 2017 11:20:30 -0700
Subject: genirq: Use cpumask_available() for check of cpumask variable
From: Matthias Kaehlcke <mka(a)chromium.org>
commit d170fe7dd992b313d4851ae5ab77ee7a51ed8c72 upstream.
This fixes the following clang warning when CONFIG_CPUMASK_OFFSTACK=n:
kernel/irq/manage.c:839:28: error: address of array
'desc->irq_common_data.affinity' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Grant Grundler <grundler(a)chromium.org>
Cc: Rusty Russell <rusty(a)rustcorp.com.au>
Cc: Greg Hackmann <ghackmann(a)google.com>
Cc: Michael Davidson <md(a)google.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Link: http://lkml.kernel.org/r/20170412182030.83657-2-mka@chromium.org
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/irq/manage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -836,7 +836,7 @@ irq_thread_check_affinity(struct irq_des
* This code is triggered unconditionally. Check the affinity
* mask pointer. For CPU_MASK_OFFSTACK=n this is optimized out.
*/
- if (desc->irq_common_data.affinity)
+ if (cpumask_available(desc->irq_common_data.affinity))
cpumask_copy(mask, desc->irq_common_data.affinity);
else
valid = false;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/dm-ioctl-remove-double-parentheses.patch
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.4/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
fs: compat: Remove warning from COMPATIBLE_IOCTL
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fs-compat-remove-warning-from-compatible_ioctl.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9280cdd6fe5b8287a726d24cc1d558b96c8491d7 Mon Sep 17 00:00:00 2001
From: Mark Charlebois <charlebm(a)gmail.com>
Date: Fri, 28 Apr 2017 15:15:12 -0700
Subject: fs: compat: Remove warning from COMPATIBLE_IOCTL
From: Mark Charlebois <charlebm(a)gmail.com>
commit 9280cdd6fe5b8287a726d24cc1d558b96c8491d7 upstream.
cmd in COMPATIBLE_IOCTL is always a u32, so cast it so there isn't a
warning about an overflow in XFORM.
From: Mark Charlebois <charlebm(a)gmail.com>
Signed-off-by: Mark Charlebois <charlebm(a)gmail.com>
Signed-off-by: Behan Webster <behanw(a)converseincode.com>
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Acked-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/compat_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -811,7 +811,7 @@ static int compat_ioctl_preallocate(stru
*/
#define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0xffffffff)
-#define COMPATIBLE_IOCTL(cmd) XFORM(cmd),
+#define COMPATIBLE_IOCTL(cmd) XFORM((u32)cmd),
/* ioctl should not be warned about even if it's not implemented.
Valid reasons to use this:
- It is implemented with ->compat_ioctl on some device, but programs
Patches currently in stable-queue which might be from charlebm(a)gmail.com are
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
This is a note to let you know that I've just added the patch titled
dm ioctl: remove double parentheses
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dm-ioctl-remove-double-parentheses.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e36215d87f301f9567c8c99fd34e6c3521a94ddf Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Mon, 17 Apr 2017 11:05:03 -0700
Subject: dm ioctl: remove double parentheses
From: Matthias Kaehlcke <mka(a)chromium.org>
commit e36215d87f301f9567c8c99fd34e6c3521a94ddf upstream.
The extra pair of parantheses is not needed and causes clang to generate
warnings about the DM_DEV_CREATE_CMD comparison in validate_params().
Also remove another double parentheses that doesn't cause a warning.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm-ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1773,12 +1773,12 @@ static int validate_params(uint cmd, str
cmd == DM_LIST_VERSIONS_CMD)
return 0;
- if ((cmd == DM_DEV_CREATE_CMD)) {
+ if (cmd == DM_DEV_CREATE_CMD) {
if (!*param->name) {
DMWARN("name not supplied when creating device");
return -EINVAL;
}
- } else if ((*param->uuid && *param->name)) {
+ } else if (*param->uuid && *param->name) {
DMWARN("only supply one of name or uuid, cmd(%u)", cmd);
return -EINVAL;
}
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/dm-ioctl-remove-double-parentheses.patch
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.4/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
cpumask: Add helper cpumask_available()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
cpumask-add-helper-cpumask_available.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f7e30f01a9e221067bb4b579e3cfc25cd2617467 Mon Sep 17 00:00:00 2001
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Wed, 12 Apr 2017 11:20:29 -0700
Subject: cpumask: Add helper cpumask_available()
From: Matthias Kaehlcke <mka(a)chromium.org>
commit f7e30f01a9e221067bb4b579e3cfc25cd2617467 upstream.
With CONFIG_CPUMASK_OFFSTACK=y cpumask_var_t is a struct cpumask
pointer, otherwise a struct cpumask array with a single element.
Some code dealing with cpumasks needs to validate that a cpumask_var_t
is not a NULL pointer when CONFIG_CPUMASK_OFFSTACK=y. This is typically
done by performing the check always, regardless of the underlying type
of cpumask_var_t. This works in both cases, however clang raises a
warning like this when CONFIG_CPUMASK_OFFSTACK=n:
kernel/irq/manage.c:839:28: error: address of array
'desc->irq_common_data.affinity' will always evaluate to 'true'
[-Werror,-Wpointer-bool-conversion]
Add the inline helper cpumask_available() which only performs the
pointer check if CONFIG_CPUMASK_OFFSTACK=y.
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Grant Grundler <grundler(a)chromium.org>
Cc: Rusty Russell <rusty(a)rustcorp.com.au>
Cc: Greg Hackmann <ghackmann(a)google.com>
Cc: Michael Davidson <md(a)google.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Link: http://lkml.kernel.org/r/20170412182030.83657-1-mka@chromium.org
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/cpumask.h | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -661,6 +661,11 @@ void alloc_bootmem_cpumask_var(cpumask_v
void free_cpumask_var(cpumask_var_t mask);
void free_bootmem_cpumask_var(cpumask_var_t mask);
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+ return mask != NULL;
+}
+
#else
typedef struct cpumask cpumask_var_t[1];
@@ -701,6 +706,11 @@ static inline void free_cpumask_var(cpum
static inline void free_bootmem_cpumask_var(cpumask_var_t mask)
{
}
+
+static inline bool cpumask_available(cpumask_var_t mask)
+{
+ return true;
+}
#endif /* CONFIG_CPUMASK_OFFSTACK */
/* It's common to want to use cpu_all_mask in struct member initializers,
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/dm-ioctl-remove-double-parentheses.patch
queue-4.4/genirq-use-cpumask_available-for-check-of-cpumask-variable.patch
queue-4.4/fs-compat-remove-warning-from-compatible_ioctl.patch
queue-4.4/selinux-remove-unnecessary-check-of-array-base-in-selinux_set_mapping.patch
queue-4.4/pci-make-pci_rom_address_mask-a-32-bit-constant.patch
queue-4.4/cpumask-add-helper-cpumask_available.patch
This is a note to let you know that I've just added the patch titled
writeback: fix the wrong congested state variable definition
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
writeback-fix-the-wrong-congested-state-variable-definition.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c877ef8ae7b8edaedccad0fc8c23d4d1de7e2480 Mon Sep 17 00:00:00 2001
From: Kaixu Xia <xiakaixu(a)huawei.com>
Date: Thu, 31 Mar 2016 13:19:41 +0000
Subject: writeback: fix the wrong congested state variable definition
From: Kaixu Xia <xiakaixu(a)huawei.com>
commit c877ef8ae7b8edaedccad0fc8c23d4d1de7e2480 upstream.
The right variable definition should be wb_congested_state that
include WB_async_congested and WB_sync_congested. So fix it.
Signed-off-by: Kaixu Xia <xiakaixu(a)huawei.com>
Acked-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Jens Axboe <axboe(a)fb.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/backing-dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -922,7 +922,7 @@ static atomic_t nr_wb_congested[2];
void clear_wb_congested(struct bdi_writeback_congested *congested, int sync)
{
wait_queue_head_t *wqh = &congestion_wqh[sync];
- enum wb_state bit;
+ enum wb_congested_state bit;
bit = sync ? WB_sync_congested : WB_async_congested;
if (test_and_clear_bit(bit, &congested->state))
@@ -935,7 +935,7 @@ EXPORT_SYMBOL(clear_wb_congested);
void set_wb_congested(struct bdi_writeback_congested *congested, int sync)
{
- enum wb_state bit;
+ enum wb_congested_state bit;
bit = sync ? WB_sync_congested : WB_async_congested;
if (!test_and_set_bit(bit, &congested->state))
Patches currently in stable-queue which might be from xiakaixu(a)huawei.com are
queue-4.4/writeback-fix-the-wrong-congested-state-variable-definition.patch
This is a note to let you know that I've just added the patch titled
ACPI, PCI, irq: remove redundant check for null string pointer
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpi-pci-irq-remove-redundant-check-for-null-string-pointer.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 45288978859119c019eff93f0cb838a0de100bcc Mon Sep 17 00:00:00 2001
From: Colin Ian King <colin.king(a)canonical.com>
Date: Tue, 5 Jan 2016 10:57:11 +0000
Subject: ACPI, PCI, irq: remove redundant check for null string pointer
From: Colin Ian King <colin.king(a)canonical.com>
commit 45288978859119c019eff93f0cb838a0de100bcc upstream.
source is decleared as a 4 byte char array in struct acpi_pci_routing_table
so !prt->source is a redundant null string pointer check. Detected with
smatch:
drivers/acpi/pci_irq.c:134 do_prt_fixups() warn: this array is probably
non-NULL. 'prt->source'
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/pci_irq.c | 3 ---
1 file changed, 3 deletions(-)
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -131,9 +131,6 @@ static void do_prt_fixups(struct acpi_pr
quirk = &prt_quirks[i];
/* All current quirks involve link devices, not GSIs */
- if (!prt->source)
- continue;
-
if (dmi_check_system(quirk->system) &&
entry->id.segment == quirk->segment &&
entry->id.bus == quirk->bus &&
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.4/acpi-pci-irq-remove-redundant-check-for-null-string-pointer.patch
On 20/03/2018 01:25 μμ, Pavlos Parissis wrote:
> On 20/03/2018 01:01 μμ, Pavlos Parissis wrote:
>> Hi,
>>
>> We were upgrading a production system from 4.14.20 to 4.14.28 and we got the following crash and I
>> was wondering if anyone has seen similar crash:
>
> According to https://www.spinics.net/lists/netdev/msg490330.html the
> https://patchwork.ozlabs.org/patch/886324/ should have fixed it, but it is not in 4.14.2[678] releases.
>
> Cheers,
> Pavlos
>
I can confirm that kernel version 4.14.32 resolves the issue.
Thanks,
Pavlos
From: Paul Parsons <lost.distance(a)yahoo.com>
Two years ago I tried an AMD Radeon E8860 embedded GPU with the drm driver.
The dmesg output included driver warnings about an invalid PCIe lane width.
Tracking the problem back led to si_set_pcie_lane_width_in_smc().
The calculation of the lane widths via ATOM_PPLIB_PCIE_LINK_WIDTH_MASK and
ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT macros did not increment the resulting
value, per the comment in pptable.h ("lanes - 1"), and per usage elsewhere.
Applying the increment silenced the warnings.
The code has not changed since, so either my analysis was incorrect or the
bug has gone unnoticed. Hence submitting this as an RFC.
Signed-off-by: Paul Parsons <lost.distance(a)yahoo.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/radeon/si_dpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 97a0a639dad9..90d5b41007bf 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -5912,9 +5912,9 @@ static void si_set_pcie_lane_width_in_smc(struct radeon_device *rdev,
{
u32 lane_width;
u32 new_lane_width =
- (radeon_new_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT;
+ ((radeon_new_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT) + 1;
u32 current_lane_width =
- (radeon_current_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT;
+ ((radeon_current_state->caps & ATOM_PPLIB_PCIE_LINK_WIDTH_MASK) >> ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT) + 1;
if (new_lane_width != current_lane_width) {
radeon_set_pcie_lanes(rdev, new_lane_width);
--
2.13.6
This is a note to let you know that I've just added the patch titled
kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c93f5cf571e7795f97d49ef51b766cf25e328545 Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Thu, 25 May 2017 19:38:17 +0900
Subject: kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
From: Masami Hiramatsu <mhiramat(a)kernel.org>
commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.
Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.
Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.
Link: http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/core.c | 9 +++++++++
kernel/kprobes.c | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -51,6 +51,7 @@
#include <linux/ftrace.h>
#include <linux/frame.h>
#include <linux/kasan.h>
+#include <linux/moduleloader.h>
#include <asm/text-patching.h>
#include <asm/cacheflush.h>
@@ -405,6 +406,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
}
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+ set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+ set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+ module_memfree(page);
+}
+
static int arch_copy_kprobe(struct kprobe *p)
{
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
}
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
{
module_memfree(page);
}
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.9/kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.patch
This is a note to let you know that I've just added the patch titled
kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c93f5cf571e7795f97d49ef51b766cf25e328545 Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Thu, 25 May 2017 19:38:17 +0900
Subject: kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
From: Masami Hiramatsu <mhiramat(a)kernel.org>
commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.
Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.
Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.
Link: http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/core.c | 9 +++++++++
kernel/kprobes.c | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -49,6 +49,7 @@
#include <linux/kdebug.h>
#include <linux/kallsyms.h>
#include <linux/ftrace.h>
+#include <linux/moduleloader.h>
#include <asm/cacheflush.h>
#include <asm/desc.h>
@@ -402,6 +403,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
}
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+ set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+ set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+ module_memfree(page);
+}
+
static int arch_copy_kprobe(struct kprobe *p)
{
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
}
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
{
module_memfree(page);
}
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-4.4/kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.patch
This is a note to let you know that I've just added the patch titled
kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c93f5cf571e7795f97d49ef51b766cf25e328545 Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu <mhiramat(a)kernel.org>
Date: Thu, 25 May 2017 19:38:17 +0900
Subject: kprobes/x86: Fix to set RWX bits correctly before releasing trampoline
From: Masami Hiramatsu <mhiramat(a)kernel.org>
commit c93f5cf571e7795f97d49ef51b766cf25e328545 upstream.
Fix kprobes to set(recover) RWX bits correctly on trampoline
buffer before releasing it. Releasing readonly page to
module_memfree() crash the kernel.
Without this fix, if kprobes user register a bunch of kprobes
in function body (since kprobes on function entry usually
use ftrace) and unregister it, kernel hits a BUG and crash.
Link: http://lkml.kernel.org/r/149570868652.3518.14120169373590420503.stgit@devbox
Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Fixes: d0381c81c2f7 ("kprobes/x86: Set kprobes pages read-only")
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/kprobes/core.c | 9 +++++++++
kernel/kprobes.c | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -49,6 +49,7 @@
#include <linux/kdebug.h>
#include <linux/kallsyms.h>
#include <linux/ftrace.h>
+#include <linux/moduleloader.h>
#include <asm/cacheflush.h>
#include <asm/desc.h>
@@ -374,6 +375,14 @@ int __copy_instruction(u8 *dest, u8 *src
return length;
}
+/* Recover page to RW mode before releasing it */
+void free_insn_page(void *page)
+{
+ set_memory_nx((unsigned long)page & PAGE_MASK, 1);
+ set_memory_rw((unsigned long)page & PAGE_MASK, 1);
+ vfree(page);
+}
+
static int arch_copy_kprobe(struct kprobe *p)
{
int ret;
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -125,7 +125,7 @@ static void *alloc_insn_page(void)
return module_alloc(PAGE_SIZE);
}
-static void free_insn_page(void *page)
+void __weak free_insn_page(void *page)
{
module_free(NULL, page);
}
Patches currently in stable-queue which might be from mhiramat(a)kernel.org are
queue-3.18/tracing-probeevent-fix-to-support-minus-offset-from-symbol.patch
queue-3.18/kprobes-x86-fix-to-set-rwx-bits-correctly-before-releasing-trampoline.patch
This is a note to let you know that I've just added the patch titled
xhci: Fix ring leak in failure path of xhci_alloc_virt_device()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xhci-fix-ring-leak-in-failure-path-of-xhci_alloc_virt_device.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3ae43090f13b7f6b6a8d4f4889727d2db4e81dd8 Mon Sep 17 00:00:00 2001
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Date: Thu, 11 Jan 2018 17:01:36 +0000
Subject: xhci: Fix ring leak in failure path of xhci_alloc_virt_device()
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
This is a stable-only fix for the backport of commit 5d9b70f7d52e
("xhci: Don't add a virt_dev to the devs array before it's fully
allocated").
In branches that predate commit c5628a2af83a ("xhci: remove endpoint
ring cache") there is an additional failure path in
xhci_alloc_virt_device() where ring cache allocation fails, in
which case we need to free the ring allocated for endpoint 0.
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Cc: Mathias Nyman <mathias.nyman(a)intel.com>
Cc: Wang Han <wanghan1995315(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1032,7 +1032,8 @@ int xhci_alloc_virt_device(struct xhci_h
return 1;
fail:
-
+ if (dev->eps[0].ring)
+ xhci_ring_free(xhci, dev->eps[0].ring);
if (dev->in_ctx)
xhci_free_container_ctx(xhci, dev->in_ctx);
if (dev->out_ctx)
Patches currently in stable-queue which might be from ben.hutchings(a)codethink.co.uk are
queue-3.18/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
queue-3.18/revert-led-core-fix-brightness-setting-when-setting-delay_off-0.patch
queue-3.18/xhci-fix-ring-leak-in-failure-path-of-xhci_alloc_virt_device.patch
This is a note to let you know that I've just added the patch titled
Revert "led: core: Fix brightness setting when setting delay_off=0"
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-led-core-fix-brightness-setting-when-setting-delay_off-0.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3f3437fbb2d8f780e84f507282d03facb4ccf248 Mon Sep 17 00:00:00 2001
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Date: Thu, 8 Mar 2018 15:59:07 +0000
Subject: Revert "led: core: Fix brightness setting when setting delay_off=0"
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
This reverts commit 20f6d9c2af33da892a0e03ffd6249c7ab81edfb7, which
was commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c upstream.
The bug that it should fix was only introduced in Linux 4.7, and
in 4.4 it causes a regression.
Reported-by: Jacek Anaszewski <jacek.anaszewski(a)gmail.com>
Cc: Matthieu CASTET <matthieu.castet(a)parrot.com>
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Cc: Wang Han <wanghan1995315(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -76,7 +76,7 @@ void led_blink_set(struct led_classdev *
unsigned long *delay_on,
unsigned long *delay_off)
{
- led_stop_software_blink(led_cdev);
+ del_timer_sync(&led_cdev->blink_timer);
led_cdev->flags &= ~LED_BLINK_ONESHOT;
led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
Patches currently in stable-queue which might be from ben.hutchings(a)codethink.co.uk are
queue-3.18/netlink-avoid-a-double-skb-free-in-genlmsg_mcast.patch
queue-3.18/revert-led-core-fix-brightness-setting-when-setting-delay_off-0.patch
queue-3.18/xhci-fix-ring-leak-in-failure-path-of-xhci_alloc_virt_device.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 16b114a6d7973cf027e4c2b23eae1076eaf98c25 Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:04 +0100
Subject: usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit 16b114a6d7973cf027e4c2b23eae1076eaf98c25 upstream.
USB spec specifies wMaxPacketSize to be little endian (as other properties),
so when using this variable in the driver we should convert to the current
CPU endianness if necessary.
This patch also introduces usb_ep_align() which does always returns the
aligned buffer size for an endpoint. This is useful to be used by USB requests
allocator functions.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/usb/gadget.h | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -663,8 +663,20 @@ static inline struct usb_gadget *dev_to_
list_for_each_entry(tmp, &(gadget)->ep_list, ep_list)
/**
+ * usb_ep_align - returns @len aligned to ep's maxpacketsize.
+ * @ep: the endpoint whose maxpacketsize is used to align @len
+ * @len: buffer size's length to align to @ep's maxpacketsize
+ *
+ * This helper is used to align buffer's size to an ep's maxpacketsize.
+ */
+static inline size_t usb_ep_align(struct usb_ep *ep, size_t len)
+{
+ return round_up(len, (size_t)le16_to_cpu(ep->desc->wMaxPacketSize));
+}
+
+/**
* usb_ep_align_maybe - returns @len aligned to ep's maxpacketsize if gadget
- * requires quirk_ep_out_aligned_size, otherwise reguens len.
+ * requires quirk_ep_out_aligned_size, otherwise returns len.
* @g: controller to check for quirk
* @ep: the endpoint whose maxpacketsize is used to align @len
* @len: buffer size's length to align to @ep's maxpacketsize
@@ -675,8 +687,7 @@ static inline struct usb_gadget *dev_to_
static inline size_t
usb_ep_align_maybe(struct usb_gadget *g, struct usb_ep *ep, size_t len)
{
- return !g->quirk_ep_out_aligned_size ? len :
- round_up(len, (size_t)ep->desc->wMaxPacketSize);
+ return g->quirk_ep_out_aligned_size ? usb_ep_align(ep, len) : len;
}
/**
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-4.4/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-4.4/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-4.4/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-4.4/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_hid: fix: Prevent accessing released memory
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-f_hid-fix-prevent-accessing-released-memory.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From aa65d11aa008f4de58a9cee7e121666d9d68505e Mon Sep 17 00:00:00 2001
From: Krzysztof Opasiak <kopasiak90(a)gmail.com>
Date: Thu, 19 Jan 2017 18:55:28 +0100
Subject: usb: gadget: f_hid: fix: Prevent accessing released memory
From: Krzysztof Opasiak <kopasiak90(a)gmail.com>
commit aa65d11aa008f4de58a9cee7e121666d9d68505e upstream.
When we unlock our spinlock to copy data to user we may get
disabled by USB host and free the whole list of completed out
requests including the one from which we are copying the data
to user memory.
To prevent from this let's remove our working element from
the list and place it back only if there is sth left when we
finish with it.
Fixes: 99c515005857 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT")
Cc: stable(a)vger.kernel.org
Tested-by: David Lechner <david(a)lechnology.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak(a)samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Jerry Zhang <zhangjerry(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_hid.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -223,6 +223,13 @@ static ssize_t f_hidg_read(struct file *
/* pick the first one */
list = list_first_entry(&hidg->completed_out_req,
struct f_hidg_req_list, list);
+
+ /*
+ * Remove this from list to protect it from beign free()
+ * while host disables our function
+ */
+ list_del(&list->list);
+
req = list->req;
count = min_t(unsigned int, count, req->actual - list->pos);
spin_unlock_irqrestore(&hidg->spinlock, flags);
@@ -238,15 +245,20 @@ static ssize_t f_hidg_read(struct file *
* call, taking into account its current read position.
*/
if (list->pos == req->actual) {
- spin_lock_irqsave(&hidg->spinlock, flags);
- list_del(&list->list);
kfree(list);
- spin_unlock_irqrestore(&hidg->spinlock, flags);
req->length = hidg->report_length;
ret = usb_ep_queue(hidg->out_ep, req, GFP_KERNEL);
- if (ret < 0)
+ if (ret < 0) {
+ free_ep_req(hidg->out_ep, req);
return ret;
+ }
+ } else {
+ spin_lock_irqsave(&hidg->spinlock, flags);
+ list_add(&list->list, &hidg->completed_out_req);
+ spin_unlock_irqrestore(&hidg->spinlock, flags);
+
+ wake_up(&hidg->read_queue);
}
return count;
@@ -490,14 +502,18 @@ static void hidg_disable(struct usb_func
{
struct f_hidg *hidg = func_to_hidg(f);
struct f_hidg_req_list *list, *next;
+ unsigned long flags;
usb_ep_disable(hidg->in_ep);
usb_ep_disable(hidg->out_ep);
+ spin_lock_irqsave(&hidg->spinlock, flags);
list_for_each_entry_safe(list, next, &hidg->completed_out_req, list) {
+ free_ep_req(hidg->out_ep, list->req);
list_del(&list->list);
kfree(list);
}
+ spin_unlock_irqrestore(&hidg->spinlock, flags);
}
static int hidg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
Patches currently in stable-queue which might be from kopasiak90(a)gmail.com are
queue-4.4/usb-gadget-f_hid-fix-prevent-accessing-released-memory.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: change len to size_t on alloc_ep_req()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 69bb99738b5c6d56d2b1a75db9cbb4d187453c1a Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:05 +0100
Subject: usb: gadget: change len to size_t on alloc_ep_req()
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit 69bb99738b5c6d56d2b1a75db9cbb4d187453c1a upstream.
Length of buffers should be of type size_t whenever possible. Altough
recommended, this change has no real practical change, unless a driver has a
uses a huge or negative buffer size - it might help find these bugs.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/u_f.c | 2 +-
drivers/usb/gadget/u_f.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/gadget/u_f.c
+++ b/drivers/usb/gadget/u_f.c
@@ -13,7 +13,7 @@
#include "u_f.h"
-struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len)
+struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len)
{
struct usb_request *req;
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -48,7 +48,7 @@ struct usb_ep;
struct usb_request;
/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
-struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len);
+struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len);
static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
{
kfree(req->buf);
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-4.4/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-4.4/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-4.4/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-4.4/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: align buffer size when allocating for OUT endpoint
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e0466156ee2e944fb47a3fa00932c3698a6d2c67 Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:06 +0100
Subject: usb: gadget: align buffer size when allocating for OUT endpoint
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit e0466156ee2e944fb47a3fa00932c3698a6d2c67 upstream.
Using usb_ep_align() makes sure that the buffer size for OUT endpoints is
always aligned with wMaxPacketSize (512 usually). This makes sure
that no buffer has the wrong size, which can cause nasty bugs.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/u_f.c | 3 +++
drivers/usb/gadget/u_f.h | 16 +++++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/u_f.c
+++ b/drivers/usb/gadget/u_f.c
@@ -12,6 +12,7 @@
*/
#include "u_f.h"
+#include <linux/usb/ch9.h>
struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len)
{
@@ -20,6 +21,8 @@ struct usb_request *alloc_ep_req(struct
req = usb_ep_alloc_request(ep, GFP_ATOMIC);
if (req) {
req->length = len ?: default_len;
+ if (usb_endpoint_dir_out(ep->desc))
+ req->length = usb_ep_align(ep, req->length);
req->buf = kmalloc(req->length, GFP_ATOMIC);
if (!req->buf) {
usb_ep_free_request(ep, req);
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -47,8 +47,22 @@
struct usb_ep;
struct usb_request;
-/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
+/**
+ * alloc_ep_req - returns a usb_request allocated by the gadget driver and
+ * allocates the request's buffer.
+ *
+ * @ep: the endpoint to allocate a usb_request
+ * @len: usb_requests's buffer suggested size
+ * @default_len: used if @len is not provided, ie, is 0
+ *
+ * In case @ep direction is OUT, the @len will be aligned to ep's
+ * wMaxPacketSize. In order to avoid memory leaks or drops, *always* use
+ * usb_requests's length (req->length) to refer to the allocated buffer size.
+ * Requests allocated via alloc_ep_req() *must* be freed by free_ep_req().
+ */
struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len);
+
+/* Frees a usb_request previously allocated by alloc_ep_req() */
static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
{
kfree(req->buf);
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-4.4/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-4.4/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-4.4/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-4.4/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 16b114a6d7973cf027e4c2b23eae1076eaf98c25 Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:04 +0100
Subject: usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit 16b114a6d7973cf027e4c2b23eae1076eaf98c25 upstream.
USB spec specifies wMaxPacketSize to be little endian (as other properties),
so when using this variable in the driver we should convert to the current
CPU endianness if necessary.
This patch also introduces usb_ep_align() which does always returns the
aligned buffer size for an endpoint. This is useful to be used by USB requests
allocator functions.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/usb/gadget.h | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -582,8 +582,20 @@ static inline struct usb_gadget *dev_to_
/**
+ * usb_ep_align - returns @len aligned to ep's maxpacketsize.
+ * @ep: the endpoint whose maxpacketsize is used to align @len
+ * @len: buffer size's length to align to @ep's maxpacketsize
+ *
+ * This helper is used to align buffer's size to an ep's maxpacketsize.
+ */
+static inline size_t usb_ep_align(struct usb_ep *ep, size_t len)
+{
+ return round_up(len, (size_t)le16_to_cpu(ep->desc->wMaxPacketSize));
+}
+
+/**
* usb_ep_align_maybe - returns @len aligned to ep's maxpacketsize if gadget
- * requires quirk_ep_out_aligned_size, otherwise reguens len.
+ * requires quirk_ep_out_aligned_size, otherwise returns len.
* @g: controller to check for quirk
* @ep: the endpoint whose maxpacketsize is used to align @len
* @len: buffer size's length to align to @ep's maxpacketsize
@@ -594,8 +606,7 @@ static inline struct usb_gadget *dev_to_
static inline size_t
usb_ep_align_maybe(struct usb_gadget *g, struct usb_ep *ep, size_t len)
{
- return !g->quirk_ep_out_aligned_size ? len :
- round_up(len, (size_t)ep->desc->wMaxPacketSize);
+ return g->quirk_ep_out_aligned_size ? usb_ep_align(ep, len) : len;
}
/**
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-3.18/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-3.18/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-3.18/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-3.18/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: change len to size_t on alloc_ep_req()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 69bb99738b5c6d56d2b1a75db9cbb4d187453c1a Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:05 +0100
Subject: usb: gadget: change len to size_t on alloc_ep_req()
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit 69bb99738b5c6d56d2b1a75db9cbb4d187453c1a upstream.
Length of buffers should be of type size_t whenever possible. Altough
recommended, this change has no real practical change, unless a driver has a
uses a huge or negative buffer size - it might help find these bugs.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/u_f.c | 2 +-
drivers/usb/gadget/u_f.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/gadget/u_f.c
+++ b/drivers/usb/gadget/u_f.c
@@ -13,7 +13,7 @@
#include "u_f.h"
-struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len)
+struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len)
{
struct usb_request *req;
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -48,7 +48,7 @@ struct usb_ep;
struct usb_request;
/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
-struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len);
+struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len);
static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
{
kfree(req->buf);
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-3.18/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-3.18/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-3.18/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-3.18/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_hid: fix: Prevent accessing released memory
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-f_hid-fix-prevent-accessing-released-memory.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From aa65d11aa008f4de58a9cee7e121666d9d68505e Mon Sep 17 00:00:00 2001
From: Krzysztof Opasiak <kopasiak90(a)gmail.com>
Date: Thu, 19 Jan 2017 18:55:28 +0100
Subject: usb: gadget: f_hid: fix: Prevent accessing released memory
From: Krzysztof Opasiak <kopasiak90(a)gmail.com>
commit aa65d11aa008f4de58a9cee7e121666d9d68505e upstream.
When we unlock our spinlock to copy data to user we may get
disabled by USB host and free the whole list of completed out
requests including the one from which we are copying the data
to user memory.
To prevent from this let's remove our working element from
the list and place it back only if there is sth left when we
finish with it.
Fixes: 99c515005857 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT")
Cc: stable(a)vger.kernel.org
Tested-by: David Lechner <david(a)lechnology.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak(a)samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Jerry Zhang <zhangjerry(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_hid.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -197,6 +197,13 @@ static ssize_t f_hidg_read(struct file *
/* pick the first one */
list = list_first_entry(&hidg->completed_out_req,
struct f_hidg_req_list, list);
+
+ /*
+ * Remove this from list to protect it from beign free()
+ * while host disables our function
+ */
+ list_del(&list->list);
+
req = list->req;
count = min_t(unsigned int, count, req->actual - list->pos);
spin_unlock_irqrestore(&hidg->spinlock, flags);
@@ -212,15 +219,20 @@ static ssize_t f_hidg_read(struct file *
* call, taking into account its current read position.
*/
if (list->pos == req->actual) {
- spin_lock_irqsave(&hidg->spinlock, flags);
- list_del(&list->list);
kfree(list);
- spin_unlock_irqrestore(&hidg->spinlock, flags);
req->length = hidg->report_length;
ret = usb_ep_queue(hidg->out_ep, req, GFP_KERNEL);
- if (ret < 0)
+ if (ret < 0) {
+ free_ep_req(hidg->out_ep, req);
return ret;
+ }
+ } else {
+ spin_lock_irqsave(&hidg->spinlock, flags);
+ list_add(&list->list, &hidg->completed_out_req);
+ spin_unlock_irqrestore(&hidg->spinlock, flags);
+
+ wake_up(&hidg->read_queue);
}
return count;
@@ -455,6 +467,7 @@ static void hidg_disable(struct usb_func
{
struct f_hidg *hidg = func_to_hidg(f);
struct f_hidg_req_list *list, *next;
+ unsigned long flags;
usb_ep_disable(hidg->in_ep);
hidg->in_ep->driver_data = NULL;
@@ -462,10 +475,13 @@ static void hidg_disable(struct usb_func
usb_ep_disable(hidg->out_ep);
hidg->out_ep->driver_data = NULL;
+ spin_lock_irqsave(&hidg->spinlock, flags);
list_for_each_entry_safe(list, next, &hidg->completed_out_req, list) {
+ free_ep_req(hidg->out_ep, list->req);
list_del(&list->list);
kfree(list);
}
+ spin_unlock_irqrestore(&hidg->spinlock, flags);
}
static int hidg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
Patches currently in stable-queue which might be from kopasiak90(a)gmail.com are
queue-3.18/usb-gadget-f_hid-fix-prevent-accessing-released-memory.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: align buffer size when allocating for OUT endpoint
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e0466156ee2e944fb47a3fa00932c3698a6d2c67 Mon Sep 17 00:00:00 2001
From: "Felipe F. Tonello" <eu(a)felipetonello.com>
Date: Mon, 8 Aug 2016 21:30:06 +0100
Subject: usb: gadget: align buffer size when allocating for OUT endpoint
From: Felipe F. Tonello <eu(a)felipetonello.com>
commit e0466156ee2e944fb47a3fa00932c3698a6d2c67 upstream.
Using usb_ep_align() makes sure that the buffer size for OUT endpoints is
always aligned with wMaxPacketSize (512 usually). This makes sure
that no buffer has the wrong size, which can cause nasty bugs.
Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/u_f.c | 3 +++
drivers/usb/gadget/u_f.h | 16 +++++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/u_f.c
+++ b/drivers/usb/gadget/u_f.c
@@ -12,6 +12,7 @@
*/
#include "u_f.h"
+#include <linux/usb/ch9.h>
struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len)
{
@@ -20,6 +21,8 @@ struct usb_request *alloc_ep_req(struct
req = usb_ep_alloc_request(ep, GFP_ATOMIC);
if (req) {
req->length = len ?: default_len;
+ if (usb_endpoint_dir_out(ep->desc))
+ req->length = usb_ep_align(ep, req->length);
req->buf = kmalloc(req->length, GFP_ATOMIC);
if (!req->buf) {
usb_ep_free_request(ep, req);
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -47,8 +47,22 @@
struct usb_ep;
struct usb_request;
-/* Requests allocated via alloc_ep_req() must be freed by free_ep_req(). */
+/**
+ * alloc_ep_req - returns a usb_request allocated by the gadget driver and
+ * allocates the request's buffer.
+ *
+ * @ep: the endpoint to allocate a usb_request
+ * @len: usb_requests's buffer suggested size
+ * @default_len: used if @len is not provided, ie, is 0
+ *
+ * In case @ep direction is OUT, the @len will be aligned to ep's
+ * wMaxPacketSize. In order to avoid memory leaks or drops, *always* use
+ * usb_requests's length (req->length) to refer to the allocated buffer size.
+ * Requests allocated via alloc_ep_req() *must* be freed by free_ep_req().
+ */
struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int default_len);
+
+/* Frees a usb_request previously allocated by alloc_ep_req() */
static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
{
kfree(req->buf);
Patches currently in stable-queue which might be from eu(a)felipetonello.com are
queue-3.18/usb-gadget-change-len-to-size_t-on-alloc_ep_req.patch
queue-3.18/usb-gadget-define-free_ep_req-as-universal-function.patch
queue-3.18/usb-gadget-fix-usb_ep_align_maybe-endianness-and-new-usb_ep_align.patch
queue-3.18/usb-gadget-align-buffer-size-when-allocating-for-out-endpoint.patch
On Mon, Apr 02, 2018 at 03:58:31PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval <osandov(a)fb.com>
>
> Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}()
> which uses memset() when the start and length are constants aligned to a
> byte. This is wrong on big-endian systems; our bitmaps are arrays of
> unsigned long, so bit n is not at byte n / 8 in memory. This was caught
> by the Btrfs selftests, but the bitmap selftests also fail when run on a
> big-endian machine.
>
> We can still use memset if the start and length are aligned to an
> unsigned long, so do that on big-endian. The same problem applies to the
> memcmp in bitmap_equal(), so fix it there, too.
>
> Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible")
> Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations")
> Cc: stable(a)kernel.org
This should be stable(a)vger.kernel.org, of course
This is a fix for a regression in 32 bit kernels caused by an
invalid check for pgoff overflow in hugetlbfs mmap setup. The
check incorrectly specified that the size of a loff_t was the
same as the size of a long. The regression prevents mapping
hugetlbfs files at offsets greater than 4GB on 32 bit kernels.
On 32 bit kernels conversion from a page based unsigned long can
not overflow a loff_t byte offset. Therefore, skip this check
if sizeof(unsigned long) != sizeof(loff_t).
Fixes: 63489f8e8211 ("hugetlbfs: check for pgoff value overflow")
Cc: <stable(a)vger.kernel.org>
Reported-by: Dan Rue <dan.rue(a)linaro.org>
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
---
fs/hugetlbfs/inode.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index b9a254dcc0e7..d508c7844681 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -138,10 +138,14 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
/*
* page based offset in vm_pgoff could be sufficiently large to
- * overflow a (l)off_t when converted to byte offset.
+ * overflow a loff_t when converted to byte offset. This can
+ * only happen on architectures where sizeof(loff_t) ==
+ * sizeof(unsigned long). So, only check in those instances.
*/
- if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
- return -EINVAL;
+ if (sizeof(unsigned long) == sizeof(loff_t)) {
+ if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
+ return -EINVAL;
+ }
/* must be huge page aligned */
if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
--
2.13.6
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -300,7 +300,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-4.9/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -300,7 +300,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-4.4/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -301,7 +301,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-4.15/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -301,7 +301,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-4.14/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
The patch below was installed in Linux 4.16-rc1 as
commit 5f15684bd5e5ef39d4337988864fec8012471dda
It is a fix to the following 4.12-rc3 patch:
commit 223220356d5ebc05ead9a8d697abb0c0a906fc81
Please install the new patch wherever the old patch was installed.
--------------------------------------------------------------------------------
UFS partitions from newer versions of FreeBSD 10 and 11 use relative addressing
for their subpartitions. But older versions of FreeBSD still use absolute
addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to also
test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
---
--- a/block/partitions/msdos.c.orig 2017-11-05 13:05:14.000000000 -0800
+++ b/block/partitions/msdos.c 2017-11-06 09:46:00.148228242 -0800
@@ -301,7 +301,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
This is a note to let you know that I've just added the patch titled
partitions/msdos: Unable to mount UFS 44bsd partitions
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5f15684bd5e5ef39d4337988864fec8012471dda Mon Sep 17 00:00:00 2001
From: Richard Narron <comet.berkeley(a)gmail.com>
Date: Wed, 10 Jan 2018 09:12:16 -0700
Subject: partitions/msdos: Unable to mount UFS 44bsd partitions
From: Richard Narron <comet.berkeley(a)gmail.com>
commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
UFS partitions from newer versions of FreeBSD 10 and 11 use relative
addressing for their subpartitions. But older versions of FreeBSD still
use absolute addressing just like OpenBSD and NetBSD.
Instead of simply testing for a FreeBSD partition, the code needs to
also test if the starting offset of the C subpartition is zero.
https://bugzilla.kernel.org/show_bug.cgi?id=197733
Signed-off-by: Richard Narron <comet.berkeley(a)gmail.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/partitions/msdos.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partitions/msdos.c
+++ b/block/partitions/msdos.c
@@ -300,7 +300,9 @@ static void parse_bsd(struct parsed_part
continue;
bsd_start = le32_to_cpu(p->p_offset);
bsd_size = le32_to_cpu(p->p_size);
- if (memcmp(flavour, "bsd\0", 4) == 0)
+ /* FreeBSD has relative offset if C partition offset is zero */
+ if (memcmp(flavour, "bsd\0", 4) == 0 &&
+ le32_to_cpu(l->d_partitions[2].p_offset) == 0)
bsd_start += offset;
if (offset == bsd_start && size == bsd_size)
/* full parent partition, we have it already */
Patches currently in stable-queue which might be from comet.berkeley(a)gmail.com are
queue-3.18/partitions-msdos-unable-to-mount-ufs-44bsd-partitions.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ff6781fd1bb404d8a551c02c35c70cec1da17ff1 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Wed, 21 Mar 2018 12:22:28 +1000
Subject: powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
From: Nicholas Piggin <npiggin(a)gmail.com>
commit ff6781fd1bb404d8a551c02c35c70cec1da17ff1 upstream.
force_external_irq_replay() can be called in the do_IRQ path with
interrupts hard enabled and soft disabled if may_hard_irq_enable() set
MSR[EE]=1. It updates local_paca->irq_happened with a load, modify,
store sequence. If a maskable interrupt hits during this sequence, it
will go to the masked handler to be marked pending in irq_happened.
This update will be lost when the interrupt returns and the store
instruction executes. This can result in unpredictable latencies,
timeouts, lockups, etc.
Fix this by ensuring hard interrupts are disabled before modifying
irq_happened.
This could cause any maskable asynchronous interrupt to get lost, but
it was noticed on P9 SMP system doing RDMA NVMe target over 100GbE,
so very high external interrupt rate and high IPI rate. The hang was
bisected down to enabling doorbell interrupts for IPIs. These provided
an interrupt type that could run at high rates in the do_IRQ path,
stressing the race.
Fixes: 1d607bb3bd60 ("powerpc/irq: Add mechanism to force a replay of interrupts")
Cc: stable(a)vger.kernel.org # v4.8+
Reported-by: Carol L. Soto <clsoto(a)us.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/irq.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -372,6 +372,14 @@ void force_external_irq_replay(void)
*/
WARN_ON(!arch_irqs_disabled());
+ /*
+ * Interrupts must always be hard disabled before irq_happened is
+ * modified (to prevent lost update in case of interrupt between
+ * load and store).
+ */
+ __hard_irq_disable();
+ local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
+
/* Indicate in the PACA that we have an interrupt to replay */
local_paca->irq_happened |= PACA_IRQ_EE;
}
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.9/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.9/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 52396500f97c53860164debc7d4f759077853423 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 23 Mar 2018 15:53:38 +1000
Subject: powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
From: Nicholas Piggin <npiggin(a)gmail.com>
commit 52396500f97c53860164debc7d4f759077853423 upstream.
The SLB bad address handler's trap number fixup does not preserve the
low bit that indicates nonvolatile GPRs have not been saved. This
leads save_nvgprs to skip saving them, and subsequent functions and
return from interrupt will think they are saved.
This causes kernel branch-to-garbage debugging to not have correct
registers, can also cause userspace to have its registers clobbered
after a segfault.
Fixes: f0f558b131db ("powerpc/mm: Preserve CFAR value on SLB miss caused by access to bogus address")
Cc: stable(a)vger.kernel.org # v4.9+
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/exceptions-64s.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -723,7 +723,7 @@ EXC_COMMON_BEGIN(bad_addr_slb)
ld r3, PACA_EXSLB+EX_DAR(r13)
std r3, _DAR(r1)
beq cr6, 2f
- li r10, 0x480 /* fix trap number for I-SLB miss */
+ li r10, 0x481 /* fix trap number for I-SLB miss */
std r10, _TRAP(r1)
2: bl save_nvgprs
addi r3, r1, STACK_FRAME_OVERHEAD
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.9/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.9/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
perf/hwbp: Simplify the perf-hwbp code, fix documentation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f67b15037a7a50c57f72e69a6d59941ad90a0f0f Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Mon, 26 Mar 2018 15:39:07 -1000
Subject: perf/hwbp: Simplify the perf-hwbp code, fix documentation
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.
Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
modification of a breakpoint - simplify it and remove the pointless
local variables.
Also update the stale Docbook while at it.
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/events/hw_breakpoint.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -427,16 +427,9 @@ EXPORT_SYMBOL_GPL(register_user_hw_break
* modify_user_hw_breakpoint - modify a user-space hardware breakpoint
* @bp: the breakpoint structure to modify
* @attr: new breakpoint attributes
- * @triggered: callback to trigger when we hit the breakpoint
- * @tsk: pointer to 'task_struct' of the process to which the address belongs
*/
int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr)
{
- u64 old_addr = bp->attr.bp_addr;
- u64 old_len = bp->attr.bp_len;
- int old_type = bp->attr.bp_type;
- int err = 0;
-
/*
* modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it
* will not be possible to raise IPIs that invoke __perf_event_disable.
@@ -451,27 +444,18 @@ int modify_user_hw_breakpoint(struct per
bp->attr.bp_addr = attr->bp_addr;
bp->attr.bp_type = attr->bp_type;
bp->attr.bp_len = attr->bp_len;
+ bp->attr.disabled = 1;
- if (attr->disabled)
- goto end;
-
- err = validate_hw_breakpoint(bp);
- if (!err)
- perf_event_enable(bp);
+ if (!attr->disabled) {
+ int err = validate_hw_breakpoint(bp);
- if (err) {
- bp->attr.bp_addr = old_addr;
- bp->attr.bp_type = old_type;
- bp->attr.bp_len = old_len;
- if (!bp->attr.disabled)
- perf_event_enable(bp);
+ if (err)
+ return err;
- return err;
+ perf_event_enable(bp);
+ bp->attr.disabled = 0;
}
-end:
- bp->attr.disabled = attr->disabled;
-
return 0;
}
EXPORT_SYMBOL_GPL(modify_user_hw_breakpoint);
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.9/perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
queue-4.9/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
mtd: jedec_probe: Fix crash in jedec_read_mfr()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Sat, 3 Mar 2018 23:29:03 +0100
Subject: mtd: jedec_probe: Fix crash in jedec_read_mfr()
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:
Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013
sp : c382dd18 ip : 0000ffff fp : 00000000
r10: c0626388 r9 : 00020000 r8 : c0626340
r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70
r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0000397f Table: 00004000 DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))
Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.
Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/chips/jedec_probe.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+ if (ofs >= map->size)
+ return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.9/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
This is a note to let you know that I've just added the patch titled
ipc/shm.c: add split function to shm_vm_ops
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipc-shm.c-add-split-function-to-shm_vm_ops.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Date: Wed, 28 Mar 2018 16:01:01 -0700
Subject: ipc/shm.c: add split function to shm_vm_ops
From: Mike Kravetz <mike.kravetz(a)oracle.com>
commit 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 upstream.
If System V shmget/shmat operations are used to create a hugetlbfs
backed mapping, it is possible to munmap part of the mapping and split
the underlying vma such that it is not huge page aligned. This will
untimately result in the following BUG:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E 4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E (4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER: 20040000
CFAR: c00000000036ee44 SOFTE: 1
NIP __unmap_hugepage_range+0xa4/0x760
LR __unmap_hugepage_range_final+0x28/0x50
Call Trace:
0x7115e4e00000 (unreliable)
__unmap_hugepage_range_final+0x28/0x50
unmap_single_vma+0x11c/0x190
unmap_vmas+0x94/0x140
exit_mmap+0x9c/0x1d0
mmput+0xa8/0x1d0
do_exit+0x360/0xc80
do_group_exit+0x60/0x100
SyS_exit_group+0x24/0x30
system_call+0x58/0x6c
---[ end trace ee88f958a1c62605 ]---
This bug was introduced by commit 31383c6865a5 ("mm, hugetlbfs:
introduce ->split() to vm_operations_struct"). A split function was
added to vm_operations_struct to determine if a mapping can be split.
This was mostly for device-dax and hugetlbfs mappings which have
specific alignment constraints.
Mappings initiated via shmget/shmat have their original vm_ops
overwritten with shm_vm_ops. shm_vm_ops functions will call back to the
original vm_ops if needed. Add such a split function to shm_vm_ops.
Link: http://lkml.kernel.org/r/20180321161314.7711-1-mike.kravetz@oracle.com
Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Manfred Spraul <manfred(a)colorfullife.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
ipc/shm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -381,6 +381,17 @@ static int shm_fault(struct vm_area_stru
return sfd->vm_ops->fault(vma, vmf);
}
+static int shm_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ if (sfd->vm_ops && sfd->vm_ops->split)
+ return sfd->vm_ops->split(vma, addr);
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
@@ -503,6 +514,7 @@ static const struct vm_operations_struct
.open = shm_open, /* callback for a new vm-area open */
.close = shm_close, /* callback for when the vm-area is released */
.fault = shm_fault,
+ .split = shm_split,
#if defined(CONFIG_NUMA)
.set_policy = shm_set_policy,
.get_policy = shm_get_policy,
Patches currently in stable-queue which might be from mike.kravetz(a)oracle.com are
queue-4.9/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
ceph: only dirty ITER_IOVEC pages for direct read
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ceph-only-dirty-iter_iovec-pages-for-direct-read.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 85784f9395987a422fa04263e7c0fb13da11eb5c Mon Sep 17 00:00:00 2001
From: "Yan, Zheng" <zyan(a)redhat.com>
Date: Fri, 16 Mar 2018 11:22:29 +0800
Subject: ceph: only dirty ITER_IOVEC pages for direct read
From: Yan, Zheng <zyan(a)redhat.com>
commit 85784f9395987a422fa04263e7c0fb13da11eb5c upstream.
If a page is already locked, attempting to dirty it leads to a deadlock
in lock_page(). This is what currently happens to ITER_BVEC pages when
a dio-enabled loop device is backed by ceph:
$ losetup --direct-io /dev/loop0 /mnt/cephfs/img
$ xfs_io -c 'pread 0 4k' /dev/loop0
Follow other file systems and only dirty ITER_IOVEC pages.
Cc: stable(a)kernel.org
Signed-off-by: "Yan, Zheng" <zyan(a)redhat.com>
Reviewed-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ceph/file.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -598,7 +598,8 @@ static ssize_t ceph_sync_read(struct kio
struct ceph_aio_request {
struct kiocb *iocb;
size_t total_len;
- int write;
+ bool write;
+ bool should_dirty;
int error;
struct list_head osd_reqs;
unsigned num_reqs;
@@ -708,7 +709,7 @@ static void ceph_aio_complete_req(struct
}
}
- ceph_put_page_vector(osd_data->pages, num_pages, !aio_req->write);
+ ceph_put_page_vector(osd_data->pages, num_pages, aio_req->should_dirty);
ceph_osdc_put_request(req);
if (rc < 0)
@@ -890,6 +891,7 @@ ceph_direct_read_write(struct kiocb *ioc
size_t count = iov_iter_count(iter);
loff_t pos = iocb->ki_pos;
bool write = iov_iter_rw(iter) == WRITE;
+ bool should_dirty = !write && iter_is_iovec(iter);
if (write && ceph_snap(file_inode(file)) != CEPH_NOSNAP)
return -EROFS;
@@ -954,6 +956,7 @@ ceph_direct_read_write(struct kiocb *ioc
if (aio_req) {
aio_req->iocb = iocb;
aio_req->write = write;
+ aio_req->should_dirty = should_dirty;
INIT_LIST_HEAD(&aio_req->osd_reqs);
if (write) {
aio_req->mtime = mtime;
@@ -1012,7 +1015,7 @@ ceph_direct_read_write(struct kiocb *ioc
len = ret;
}
- ceph_put_page_vector(pages, num_pages, !write);
+ ceph_put_page_vector(pages, num_pages, should_dirty);
ceph_osdc_put_request(req);
if (ret < 0)
Patches currently in stable-queue which might be from zyan(a)redhat.com are
queue-4.9/ceph-only-dirty-iter_iovec-pages-for-direct-read.patch
This is a note to let you know that I've just added the patch titled
ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_state.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a Mon Sep 17 00:00:00 2001
From: Fabio Estevam <festevam(a)gmail.com>
Date: Mon, 22 Jan 2018 12:20:26 +0100
Subject: ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
From: Fabio Estevam <festevam(a)gmail.com>
commit 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a upstream.
Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
for dying cpu") fixed the cpu dying notifier by clearing
vfp_current_hw_state[]. However commit e5b61bafe704 ("arm: Convert VFP
hotplug notifiers to state machine") incorrectly used the original
vfp_force_reload() function in the cpu dying notifier.
Fix it by going back to clearing vfp_current_hw_state[].
Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
Cc: linux-stable <stable(a)vger.kernel.org>
Reported-by: Kohji Okuno <okuno.kohji(a)jp.panasonic.com>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/vfp/vfpmodule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -648,7 +648,7 @@ int vfp_restore_user_hwstate(struct user
*/
static int vfp_dying_cpu(unsigned int cpu)
{
- vfp_force_reload(cpu, current_thread_info());
+ vfp_current_hw_state[cpu] = NULL;
return 0;
}
Patches currently in stable-queue which might be from festevam(a)gmail.com are
queue-4.9/arm-8746-1-vfp-go-back-to-clearing-vfp_current_hw_state.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Add native DSD support for TEAC UD-301
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b00214865d65100163574ba250008f182cf90869 Mon Sep 17 00:00:00 2001
From: Nobutaka Okabe <nob77413(a)gmail.com>
Date: Fri, 23 Mar 2018 19:49:44 +0900
Subject: ALSA: usb-audio: Add native DSD support for TEAC UD-301
From: Nobutaka Okabe <nob77413(a)gmail.com>
commit b00214865d65100163574ba250008f182cf90869 upstream.
Add native DSD support quirk for TEAC UD-301 DAC,
by adding the PID/VID 0644:804a.
Signed-off-by: Nobutaka Okabe <nob77413(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/quirks.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1175,6 +1175,7 @@ static bool is_teac_dsd_dac(unsigned int
switch (id) {
case USB_ID(0x0644, 0x8043): /* TEAC UD-501/UD-503/NT-503 */
case USB_ID(0x0644, 0x8044): /* Esoteric D-05X */
+ case USB_ID(0x0644, 0x804a): /* TEAC UD-301 */
return true;
}
return false;
Patches currently in stable-queue which might be from nob77413(a)gmail.com are
queue-4.9/alsa-usb-audio-add-native-dsd-support-for-teac-ud-301.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9066ae7ff5d89c0b5daa271e2d573540097a94fa Mon Sep 17 00:00:00 2001
From: Stefan Roese <sr(a)denx.de>
Date: Mon, 26 Mar 2018 16:10:21 +0200
Subject: ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
From: Stefan Roese <sr(a)denx.de>
commit 9066ae7ff5d89c0b5daa271e2d573540097a94fa upstream.
When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer
will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB
area, as the page offset is outside of the VMA range (size), which is
currently used as size parameter in snd_pcm_lib_default_mmap(). By
using the DMA buffer size (dma_bytes) instead, the complete DMA buffer
can be mmapp'ed and the issue is fixed.
This issue was detected on an ARM platform (TI AM57xx) using the RME
HDSP MADI PCIe soundcard.
Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available")
Signed-off-by: Stefan Roese <sr(a)denx.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3410,7 +3410,7 @@ int snd_pcm_lib_default_mmap(struct snd_
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
- area->vm_end - area->vm_start);
+ substream->runtime->dma_bytes);
#endif /* CONFIG_X86 */
/* mmap with fault handler */
area->vm_ops = &snd_pcm_vm_ops_data_fault;
Patches currently in stable-queue which might be from sr(a)denx.de are
queue-4.9/alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: potential uninitialized return values
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-pcm-potential-uninitialized-return-values.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 27 Mar 2018 16:07:52 +0300
Subject: ALSA: pcm: potential uninitialized return values
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 upstream.
Smatch complains that "tmp" can be uninitialized if we do a zero size
write.
Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1361,7 +1361,7 @@ static ssize_t snd_pcm_oss_write2(struct
static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
@@ -1468,7 +1468,7 @@ static ssize_t snd_pcm_oss_read2(struct
static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/alsa-pcm-potential-uninitialized-return-values.patch
This is a note to let you know that I've just added the patch titled
perf/hwbp: Simplify the perf-hwbp code, fix documentation
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f67b15037a7a50c57f72e69a6d59941ad90a0f0f Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Mon, 26 Mar 2018 15:39:07 -1000
Subject: perf/hwbp: Simplify the perf-hwbp code, fix documentation
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.
Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
modification of a breakpoint - simplify it and remove the pointless
local variables.
Also update the stale Docbook while at it.
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/events/hw_breakpoint.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -427,16 +427,9 @@ EXPORT_SYMBOL_GPL(register_user_hw_break
* modify_user_hw_breakpoint - modify a user-space hardware breakpoint
* @bp: the breakpoint structure to modify
* @attr: new breakpoint attributes
- * @triggered: callback to trigger when we hit the breakpoint
- * @tsk: pointer to 'task_struct' of the process to which the address belongs
*/
int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr)
{
- u64 old_addr = bp->attr.bp_addr;
- u64 old_len = bp->attr.bp_len;
- int old_type = bp->attr.bp_type;
- int err = 0;
-
/*
* modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it
* will not be possible to raise IPIs that invoke __perf_event_disable.
@@ -451,27 +444,18 @@ int modify_user_hw_breakpoint(struct per
bp->attr.bp_addr = attr->bp_addr;
bp->attr.bp_type = attr->bp_type;
bp->attr.bp_len = attr->bp_len;
+ bp->attr.disabled = 1;
- if (attr->disabled)
- goto end;
-
- err = validate_hw_breakpoint(bp);
- if (!err)
- perf_event_enable(bp);
+ if (!attr->disabled) {
+ int err = validate_hw_breakpoint(bp);
- if (err) {
- bp->attr.bp_addr = old_addr;
- bp->attr.bp_type = old_type;
- bp->attr.bp_len = old_len;
- if (!bp->attr.disabled)
- perf_event_enable(bp);
+ if (err)
+ return err;
- return err;
+ perf_event_enable(bp);
+ bp->attr.disabled = 0;
}
-end:
- bp->attr.disabled = attr->disabled;
-
return 0;
}
EXPORT_SYMBOL_GPL(modify_user_hw_breakpoint);
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.4/perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
This is a note to let you know that I've just added the patch titled
mtd: jedec_probe: Fix crash in jedec_read_mfr()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Sat, 3 Mar 2018 23:29:03 +0100
Subject: mtd: jedec_probe: Fix crash in jedec_read_mfr()
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:
Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013
sp : c382dd18 ip : 0000ffff fp : 00000000
r10: c0626388 r9 : 00020000 r8 : c0626340
r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70
r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0000397f Table: 00004000 DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))
Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.
Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/chips/jedec_probe.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+ if (ofs >= map->size)
+ return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.4/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9066ae7ff5d89c0b5daa271e2d573540097a94fa Mon Sep 17 00:00:00 2001
From: Stefan Roese <sr(a)denx.de>
Date: Mon, 26 Mar 2018 16:10:21 +0200
Subject: ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
From: Stefan Roese <sr(a)denx.de>
commit 9066ae7ff5d89c0b5daa271e2d573540097a94fa upstream.
When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer
will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB
area, as the page offset is outside of the VMA range (size), which is
currently used as size parameter in snd_pcm_lib_default_mmap(). By
using the DMA buffer size (dma_bytes) instead, the complete DMA buffer
can be mmapp'ed and the issue is fixed.
This issue was detected on an ARM platform (TI AM57xx) using the RME
HDSP MADI PCIe soundcard.
Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available")
Signed-off-by: Stefan Roese <sr(a)denx.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/pcm_native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3408,7 +3408,7 @@ int snd_pcm_lib_default_mmap(struct snd_
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
- area->vm_end - area->vm_start);
+ substream->runtime->dma_bytes);
#endif /* CONFIG_X86 */
/* mmap with fault handler */
area->vm_ops = &snd_pcm_vm_ops_data_fault;
Patches currently in stable-queue which might be from sr(a)denx.de are
queue-4.4/alsa-pcm-use-dma_bytes-as-size-parameter-in-dma_mmap_coherent.patch
This is a note to let you know that I've just added the patch titled
ALSA: pcm: potential uninitialized return values
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-pcm-potential-uninitialized-return-values.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 27 Mar 2018 16:07:52 +0300
Subject: ALSA: pcm: potential uninitialized return values
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 upstream.
Smatch complains that "tmp" can be uninitialized if we do a zero size
write.
Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -1361,7 +1361,7 @@ static ssize_t snd_pcm_oss_write2(struct
static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
@@ -1468,7 +1468,7 @@ static ssize_t snd_pcm_oss_read2(struct
static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes)
{
size_t xfer = 0;
- ssize_t tmp;
+ ssize_t tmp = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
if (atomic_read(&substream->mmap_count))
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.4/alsa-pcm-potential-uninitialized-return-values.patch
This is a note to let you know that I've just added the patch titled
x86/platform/uv/BAU: Add APIC idt entry
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-platform-uv-bau-add-apic-idt-entry.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 151ad17fbe5e56afa59709f41980508672c777ce Mon Sep 17 00:00:00 2001
From: Andrew Banman <abanman(a)hpe.com>
Date: Tue, 27 Mar 2018 17:09:06 -0500
Subject: x86/platform/uv/BAU: Add APIC idt entry
From: Andrew Banman <abanman(a)hpe.com>
commit 151ad17fbe5e56afa59709f41980508672c777ce upstream.
BAU uses the old alloc_initr_gate90 method to setup its interrupt. This
fails silently as the BAU vector is in the range of APIC vectors that are
registered to the spurious interrupt handler. As a consequence BAU
broadcasts are not handled, and the broadcast source CPU hangs.
Update BAU to use new idt structure.
Fixes: dc20b2d52653 ("x86/idt: Move interrupt gate initialization to IDT code")
Signed-off-by: Andrew Banman <abanman(a)hpe.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Mike Travis <mike.travis(a)hpe.com>
Cc: Dimitri Sivanich <sivanich(a)hpe.com>
Cc: Russ Anderson <rja(a)hpe.com>
Cc: stable(a)vger.kernel.org
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Link: https://lkml.kernel.org/r/1522188546-196177-1-git-send-email-abanman@hpe.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/hw_irq.h | 1 +
arch/x86/kernel/idt.c | 3 +++
arch/x86/platform/uv/tlb_uv.c | 2 --
3 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -36,6 +36,7 @@ extern asmlinkage void kvm_posted_intr_w
extern asmlinkage void kvm_posted_intr_nested_ipi(void);
extern asmlinkage void error_interrupt(void);
extern asmlinkage void irq_work_interrupt(void);
+extern asmlinkage void uv_bau_message_intr1(void);
extern asmlinkage void spurious_interrupt(void);
extern asmlinkage void thermal_interrupt(void);
--- a/arch/x86/kernel/idt.c
+++ b/arch/x86/kernel/idt.c
@@ -140,6 +140,9 @@ static const __initconst struct idt_data
# ifdef CONFIG_IRQ_WORK
INTG(IRQ_WORK_VECTOR, irq_work_interrupt),
# endif
+#ifdef CONFIG_X86_UV
+ INTG(UV_BAU_MESSAGE, uv_bau_message_intr1),
+#endif
INTG(SPURIOUS_APIC_VECTOR, spurious_interrupt),
INTG(ERROR_APIC_VECTOR, error_interrupt),
#endif
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -2254,8 +2254,6 @@ static int __init uv_bau_init(void)
init_uvhub(uvhub, vector, uv_base_pnode);
}
- alloc_intr_gate(vector, uv_bau_message_intr1);
-
for_each_possible_blade(uvhub) {
if (uv_blade_nr_possible_cpus(uvhub)) {
unsigned long val;
Patches currently in stable-queue which might be from abanman(a)hpe.com are
queue-4.15/x86-platform-uv-bau-add-apic-idt-entry.patch
This is a note to let you know that I've just added the patch titled
powerpc/mm: Workaround Nest MMU bug with TLB invalidations
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-mm-workaround-nest-mmu-bug-with-tlb-invalidations.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 80a4ae202f2d319eced8bbf612a4e8b0f11c21f5 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Date: Fri, 23 Mar 2018 09:29:06 +1100
Subject: powerpc/mm: Workaround Nest MMU bug with TLB invalidations
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
commit 80a4ae202f2d319eced8bbf612a4e8b0f11c21f5 upstream.
On POWER9 the Nest MMU may fail to invalidate some translations when
doing a tlbie "by PID" or "by LPID" that is targeted at the TLB only
and not the page walk cache.
This works around it by forcing such invalidations to escalate to
RIC=2 (full invalidation of TLB *and* PWC) when a coprocessor is in
use for the context.
Fixes: 03b8abedf4f4 ("cxl: Enable global TLBIs for cxl contexts")
Cc: stable(a)vger.kernel.org # v4.15+
Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Signed-off-by: Balbir Singh <bsingharora(a)gmail.com>
[balbirs: fixed spelling and coding style to quiesce checkpatch.pl]
Tested-by: Balbir Singh <bsingharora(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/mm/tlb-radix.c | 50 +++++++++++++++++++++++++++++++++++++-------
1 file changed, 43 insertions(+), 7 deletions(-)
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@ -85,7 +85,23 @@ static inline void _tlbiel_pid(unsigned
static inline void _tlbie_pid(unsigned long pid, unsigned long ric)
{
asm volatile("ptesync": : :"memory");
- __tlbie_pid(pid, ric);
+
+ /*
+ * Workaround the fact that the "ric" argument to __tlbie_pid
+ * must be a compile-time contraint to match the "i" constraint
+ * in the asm statement.
+ */
+ switch (ric) {
+ case RIC_FLUSH_TLB:
+ __tlbie_pid(pid, RIC_FLUSH_TLB);
+ break;
+ case RIC_FLUSH_PWC:
+ __tlbie_pid(pid, RIC_FLUSH_PWC);
+ break;
+ case RIC_FLUSH_ALL:
+ default:
+ __tlbie_pid(pid, RIC_FLUSH_ALL);
+ }
asm volatile("eieio; tlbsync; ptesync": : :"memory");
}
@@ -245,6 +261,16 @@ void radix__local_flush_tlb_page(struct
}
EXPORT_SYMBOL(radix__local_flush_tlb_page);
+static bool mm_needs_flush_escalation(struct mm_struct *mm)
+{
+ /*
+ * P9 nest MMU has issues with the page walk cache
+ * caching PTEs and not flushing them properly when
+ * RIC = 0 for a PID/LPID invalidate
+ */
+ return atomic_read(&mm->context.copros) != 0;
+}
+
#ifdef CONFIG_SMP
void radix__flush_tlb_mm(struct mm_struct *mm)
{
@@ -255,9 +281,12 @@ void radix__flush_tlb_mm(struct mm_struc
return;
preempt_disable();
- if (!mm_is_thread_local(mm))
- _tlbie_pid(pid, RIC_FLUSH_TLB);
- else
+ if (!mm_is_thread_local(mm)) {
+ if (mm_needs_flush_escalation(mm))
+ _tlbie_pid(pid, RIC_FLUSH_ALL);
+ else
+ _tlbie_pid(pid, RIC_FLUSH_TLB);
+ } else
_tlbiel_pid(pid, RIC_FLUSH_TLB);
preempt_enable();
}
@@ -369,10 +398,14 @@ void radix__flush_tlb_range(struct vm_ar
}
if (full) {
- if (local)
+ if (local) {
_tlbiel_pid(pid, RIC_FLUSH_TLB);
- else
- _tlbie_pid(pid, RIC_FLUSH_TLB);
+ } else {
+ if (mm_needs_flush_escalation(mm))
+ _tlbie_pid(pid, RIC_FLUSH_ALL);
+ else
+ _tlbie_pid(pid, RIC_FLUSH_TLB);
+ }
} else {
bool hflush = false;
unsigned long hstart, hend;
@@ -482,6 +515,9 @@ static inline void __radix__flush_tlb_ra
}
if (full) {
+ if (!local && mm_needs_flush_escalation(mm))
+ also_pwc = true;
+
if (local)
_tlbiel_pid(pid, also_pwc ? RIC_FLUSH_ALL : RIC_FLUSH_TLB);
else
Patches currently in stable-queue which might be from benh(a)kernel.crashing.org are
queue-4.15/powerpc-mm-add-tracking-of-the-number-of-coprocessors-using-a-context.patch
queue-4.15/powerpc-mm-workaround-nest-mmu-bug-with-tlb-invalidations.patch
This is a note to let you know that I've just added the patch titled
powerpc/mm: Add tracking of the number of coprocessors using a context
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-mm-add-tracking-of-the-number-of-coprocessors-using-a-context.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From aff6f8cb3e2170b9e58b0932bce7bfb492775e23 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Date: Fri, 23 Mar 2018 09:29:05 +1100
Subject: powerpc/mm: Add tracking of the number of coprocessors using a context
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
commit aff6f8cb3e2170b9e58b0932bce7bfb492775e23 upstream.
Currently, when using coprocessors (which use the Nest MMU), we
simply increment the active_cpu count to force all TLB invalidations
to be come broadcast.
Unfortunately, due to an errata in POWER9, we will need to know
more specifically that coprocessors are in use.
This maintains a separate copros counter in the MMU context for
that purpose.
NB. The commit mentioned in the fixes tag below is not at fault for
the bug we're fixing in this commit and the next, but this fix applies
on top the infrastructure it introduced.
Fixes: 03b8abedf4f4 ("cxl: Enable global TLBIs for cxl contexts")
Cc: stable(a)vger.kernel.org # v4.15+
Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Tested-by: Balbir Singh <bsingharora(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/book3s/64/mmu.h | 3 +++
arch/powerpc/include/asm/mmu_context.h | 18 +++++++++++++-----
arch/powerpc/mm/mmu_context_book3s64.c | 1 +
3 files changed, 17 insertions(+), 5 deletions(-)
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -87,6 +87,9 @@ typedef struct {
/* Number of bits in the mm_cpumask */
atomic_t active_cpus;
+ /* Number of users of the external (Nest) MMU */
+ atomic_t copros;
+
/* NPU NMMU context */
struct npu_context *npu_context;
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -92,15 +92,23 @@ static inline void dec_mm_active_cpus(st
static inline void mm_context_add_copro(struct mm_struct *mm)
{
/*
- * On hash, should only be called once over the lifetime of
- * the context, as we can't decrement the active cpus count
- * and flush properly for the time being.
+ * If any copro is in use, increment the active CPU count
+ * in order to force TLB invalidations to be global as to
+ * propagate to the Nest MMU.
*/
- inc_mm_active_cpus(mm);
+ if (atomic_inc_return(&mm->context.copros) == 1)
+ inc_mm_active_cpus(mm);
}
static inline void mm_context_remove_copro(struct mm_struct *mm)
{
+ int c;
+
+ c = atomic_dec_if_positive(&mm->context.copros);
+
+ /* Detect imbalance between add and remove */
+ WARN_ON(c < 0);
+
/*
* Need to broadcast a global flush of the full mm before
* decrementing active_cpus count, as the next TLBI may be
@@ -111,7 +119,7 @@ static inline void mm_context_remove_cop
* for the time being. Invalidations will remain global if
* used on hash.
*/
- if (radix_enabled()) {
+ if (c == 0 && radix_enabled()) {
flush_all_mm(mm);
dec_mm_active_cpus(mm);
}
--- a/arch/powerpc/mm/mmu_context_book3s64.c
+++ b/arch/powerpc/mm/mmu_context_book3s64.c
@@ -171,6 +171,7 @@ int init_new_context(struct task_struct
mm_iommu_init(mm);
#endif
atomic_set(&mm->context.active_cpus, 0);
+ atomic_set(&mm->context.copros, 0);
return 0;
}
Patches currently in stable-queue which might be from benh(a)kernel.crashing.org are
queue-4.15/powerpc-mm-add-tracking-of-the-number-of-coprocessors-using-a-context.patch
queue-4.15/powerpc-mm-workaround-nest-mmu-bug-with-tlb-invalidations.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ff6781fd1bb404d8a551c02c35c70cec1da17ff1 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Wed, 21 Mar 2018 12:22:28 +1000
Subject: powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
From: Nicholas Piggin <npiggin(a)gmail.com>
commit ff6781fd1bb404d8a551c02c35c70cec1da17ff1 upstream.
force_external_irq_replay() can be called in the do_IRQ path with
interrupts hard enabled and soft disabled if may_hard_irq_enable() set
MSR[EE]=1. It updates local_paca->irq_happened with a load, modify,
store sequence. If a maskable interrupt hits during this sequence, it
will go to the masked handler to be marked pending in irq_happened.
This update will be lost when the interrupt returns and the store
instruction executes. This can result in unpredictable latencies,
timeouts, lockups, etc.
Fix this by ensuring hard interrupts are disabled before modifying
irq_happened.
This could cause any maskable asynchronous interrupt to get lost, but
it was noticed on P9 SMP system doing RDMA NVMe target over 100GbE,
so very high external interrupt rate and high IPI rate. The hang was
bisected down to enabling doorbell interrupts for IPIs. These provided
an interrupt type that could run at high rates in the do_IRQ path,
stressing the race.
Fixes: 1d607bb3bd60 ("powerpc/irq: Add mechanism to force a replay of interrupts")
Cc: stable(a)vger.kernel.org # v4.8+
Reported-by: Carol L. Soto <clsoto(a)us.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/irq.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -475,6 +475,14 @@ void force_external_irq_replay(void)
*/
WARN_ON(!arch_irqs_disabled());
+ /*
+ * Interrupts must always be hard disabled before irq_happened is
+ * modified (to prevent lost update in case of interrupt between
+ * load and store).
+ */
+ __hard_irq_disable();
+ local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
+
/* Indicate in the PACA that we have an interrupt to replay */
local_paca->irq_happened |= PACA_IRQ_EE;
}
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.15/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.15/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 52396500f97c53860164debc7d4f759077853423 Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Fri, 23 Mar 2018 15:53:38 +1000
Subject: powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
From: Nicholas Piggin <npiggin(a)gmail.com>
commit 52396500f97c53860164debc7d4f759077853423 upstream.
The SLB bad address handler's trap number fixup does not preserve the
low bit that indicates nonvolatile GPRs have not been saved. This
leads save_nvgprs to skip saving them, and subsequent functions and
return from interrupt will think they are saved.
This causes kernel branch-to-garbage debugging to not have correct
registers, can also cause userspace to have its registers clobbered
after a segfault.
Fixes: f0f558b131db ("powerpc/mm: Preserve CFAR value on SLB miss caused by access to bogus address")
Cc: stable(a)vger.kernel.org # v4.9+
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/exceptions-64s.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -706,7 +706,7 @@ EXC_COMMON_BEGIN(bad_addr_slb)
ld r3, PACA_EXSLB+EX_DAR(r13)
std r3, _DAR(r1)
beq cr6, 2f
- li r10, 0x480 /* fix trap number for I-SLB miss */
+ li r10, 0x481 /* fix trap number for I-SLB miss */
std r10, _TRAP(r1)
2: bl save_nvgprs
addi r3, r1, STACK_FRAME_OVERHEAD
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.15/powerpc-64s-fix-lost-pending-interrupt-due-to-race-causing-lost-update-to-irq_happened.patch
queue-4.15/powerpc-64s-fix-i-side-slb-miss-bad-address-handler-saving-nonvolatile-gprs.patch
This is a note to let you know that I've just added the patch titled
perf/hwbp: Simplify the perf-hwbp code, fix documentation
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f67b15037a7a50c57f72e69a6d59941ad90a0f0f Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Mon, 26 Mar 2018 15:39:07 -1000
Subject: perf/hwbp: Simplify the perf-hwbp code, fix documentation
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.
Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
modification of a breakpoint - simplify it and remove the pointless
local variables.
Also update the stale Docbook while at it.
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: <stable(a)vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Frederic Weisbecker <fweisbec(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Vince Weaver <vincent.weaver(a)maine.edu>
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/events/hw_breakpoint.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -427,16 +427,9 @@ EXPORT_SYMBOL_GPL(register_user_hw_break
* modify_user_hw_breakpoint - modify a user-space hardware breakpoint
* @bp: the breakpoint structure to modify
* @attr: new breakpoint attributes
- * @triggered: callback to trigger when we hit the breakpoint
- * @tsk: pointer to 'task_struct' of the process to which the address belongs
*/
int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr)
{
- u64 old_addr = bp->attr.bp_addr;
- u64 old_len = bp->attr.bp_len;
- int old_type = bp->attr.bp_type;
- int err = 0;
-
/*
* modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it
* will not be possible to raise IPIs that invoke __perf_event_disable.
@@ -451,27 +444,18 @@ int modify_user_hw_breakpoint(struct per
bp->attr.bp_addr = attr->bp_addr;
bp->attr.bp_type = attr->bp_type;
bp->attr.bp_len = attr->bp_len;
+ bp->attr.disabled = 1;
- if (attr->disabled)
- goto end;
-
- err = validate_hw_breakpoint(bp);
- if (!err)
- perf_event_enable(bp);
+ if (!attr->disabled) {
+ int err = validate_hw_breakpoint(bp);
- if (err) {
- bp->attr.bp_addr = old_addr;
- bp->attr.bp_type = old_type;
- bp->attr.bp_len = old_len;
- if (!bp->attr.disabled)
- perf_event_enable(bp);
+ if (err)
+ return err;
- return err;
+ perf_event_enable(bp);
+ bp->attr.disabled = 0;
}
-end:
- bp->attr.disabled = attr->disabled;
-
return 0;
}
EXPORT_SYMBOL_GPL(modify_user_hw_breakpoint);
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.15/perf-hwbp-simplify-the-perf-hwbp-code-fix-documentation.patch
queue-4.15/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: atmel: Fix get_sectorsize() function
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-nand-atmel-fix-get_sectorsize-function.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2b1b1b4ac716fd929a2d221bd4ade62263bed915 Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
Date: Tue, 27 Mar 2018 19:01:58 +0200
Subject: mtd: nand: atmel: Fix get_sectorsize() function
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
commit 2b1b1b4ac716fd929a2d221bd4ade62263bed915 upstream.
get_sectorsize() was not using the appropriate macro to extract the
ECC sector size from the config cache, which led to buggy ECC when
using 1024 byte sectors.
Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Cc: <stable(a)vger.kernel.org>
Reported-by: Olivier Schonken <olivier.schonken(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Acked-by: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Tested-by: Olivier Schonken <olivier.schonken(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/atmel/pmecc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/nand/atmel/pmecc.c
+++ b/drivers/mtd/nand/atmel/pmecc.c
@@ -426,7 +426,7 @@ static int get_strength(struct atmel_pme
static int get_sectorsize(struct atmel_pmecc_user *user)
{
- return user->cache.cfg & PMECC_LOOKUP_TABLE_SIZE_1024 ? 1024 : 512;
+ return user->cache.cfg & PMECC_CFG_SECTOR1024 ? 1024 : 512;
}
static void atmel_pmecc_gen_syndrome(struct atmel_pmecc_user *user, int sector)
Patches currently in stable-queue which might be from boris.brezillon(a)bootlin.com are
queue-4.15/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
queue-4.15/mtd-nand-atmel-fix-get_sectorsize-function.patch
This is a note to let you know that I've just added the patch titled
mtd: jedec_probe: Fix crash in jedec_read_mfr()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Sat, 3 Mar 2018 23:29:03 +0100
Subject: mtd: jedec_probe: Fix crash in jedec_read_mfr()
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:
Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013
sp : c382dd18 ip : 0000ffff fp : 00000000
r10: c0626388 r9 : 00020000 r8 : c0626340
r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70
r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0000397f Table: 00004000 DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))
Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.
Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/chips/jedec_probe.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1889,6 +1889,8 @@ static inline u32 jedec_read_mfr(struct
do {
uint32_t ofs = cfi_build_cmd_addr(0 + (bank << 8), map, cfi);
mask = (1 << (cfi->device_type * 8)) - 1;
+ if (ofs >= map->size)
+ return 0;
result = map_read(map, base + ofs);
bank++;
} while ((result.x[0] & mask) == CFI_MFR_CONTINUATION);
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.15/mtd-jedec_probe-fix-crash-in-jedec_read_mfr.patch
This is a note to let you know that I've just added the patch titled
ipc/shm.c: add split function to shm_vm_ops
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipc-shm.c-add-split-function-to-shm_vm_ops.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Date: Wed, 28 Mar 2018 16:01:01 -0700
Subject: ipc/shm.c: add split function to shm_vm_ops
From: Mike Kravetz <mike.kravetz(a)oracle.com>
commit 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 upstream.
If System V shmget/shmat operations are used to create a hugetlbfs
backed mapping, it is possible to munmap part of the mapping and split
the underlying vma such that it is not huge page aligned. This will
untimately result in the following BUG:
kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
Oops: Exception in kernel mode, sig: 5 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E 4.15.0-10-generic #11-Ubuntu
NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E (4.15.0-10-generic)
MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER: 20040000
CFAR: c00000000036ee44 SOFTE: 1
NIP __unmap_hugepage_range+0xa4/0x760
LR __unmap_hugepage_range_final+0x28/0x50
Call Trace:
0x7115e4e00000 (unreliable)
__unmap_hugepage_range_final+0x28/0x50
unmap_single_vma+0x11c/0x190
unmap_vmas+0x94/0x140
exit_mmap+0x9c/0x1d0
mmput+0xa8/0x1d0
do_exit+0x360/0xc80
do_group_exit+0x60/0x100
SyS_exit_group+0x24/0x30
system_call+0x58/0x6c
---[ end trace ee88f958a1c62605 ]---
This bug was introduced by commit 31383c6865a5 ("mm, hugetlbfs:
introduce ->split() to vm_operations_struct"). A split function was
added to vm_operations_struct to determine if a mapping can be split.
This was mostly for device-dax and hugetlbfs mappings which have
specific alignment constraints.
Mappings initiated via shmget/shmat have their original vm_ops
overwritten with shm_vm_ops. shm_vm_ops functions will call back to the
original vm_ops if needed. Add such a split function to shm_vm_ops.
Link: http://lkml.kernel.org/r/20180321161314.7711-1-mike.kravetz@oracle.com
Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Manfred Spraul <manfred(a)colorfullife.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
ipc/shm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -386,6 +386,17 @@ static int shm_fault(struct vm_fault *vm
return sfd->vm_ops->fault(vmf);
}
+static int shm_split(struct vm_area_struct *vma, unsigned long addr)
+{
+ struct file *file = vma->vm_file;
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ if (sfd->vm_ops && sfd->vm_ops->split)
+ return sfd->vm_ops->split(vma, addr);
+
+ return 0;
+}
+
#ifdef CONFIG_NUMA
static int shm_set_policy(struct vm_area_struct *vma, struct mempolicy *new)
{
@@ -510,6 +521,7 @@ static const struct vm_operations_struct
.open = shm_open, /* callback for a new vm-area open */
.close = shm_close, /* callback for when the vm-area is released */
.fault = shm_fault,
+ .split = shm_split,
#if defined(CONFIG_NUMA)
.set_policy = shm_set_policy,
.get_policy = shm_get_policy,
Patches currently in stable-queue which might be from mike.kravetz(a)oracle.com are
queue-4.15/ipc-shm.c-add-split-function-to-shm_vm_ops.patch
This is a note to let you know that I've just added the patch titled
i2c: i2c-stm32f7: fix no check on returned setup
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i2c-i2c-stm32f7-fix-no-check-on-returned-setup.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 771b7bf05339081019d22452ebcab6929372e13e Mon Sep 17 00:00:00 2001
From: Pierre-Yves MORDRET <pierre-yves.mordret(a)st.com>
Date: Wed, 21 Mar 2018 17:48:40 +0100
Subject: i2c: i2c-stm32f7: fix no check on returned setup
From: Pierre-Yves MORDRET <pierre-yves.mordret(a)st.com>
commit 771b7bf05339081019d22452ebcab6929372e13e upstream.
Before assigning returned setup structure check if not null
Fixes: 463a9215f3ca7600b5ff ("i2c: stm32f7: fix setup structure")
Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret(a)st.com>
Acked-by: Alexandre TORGUE <alexandre.torgue(a)st.com>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Cc: stable(a)kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/busses/i2c-stm32f7.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -888,6 +888,11 @@ static int stm32f7_i2c_probe(struct plat
}
setup = of_device_get_match_data(&pdev->dev);
+ if (!setup) {
+ dev_err(&pdev->dev, "Can't get device data\n");
+ ret = -ENODEV;
+ goto clk_free;
+ }
i2c_dev->setup = *setup;
ret = device_property_read_u32(i2c_dev->dev, "i2c-scl-rising-time-ns",
Patches currently in stable-queue which might be from pierre-yves.mordret(a)st.com are
queue-4.15/i2c-i2c-stm32f7-fix-no-check-on-returned-setup.patch
This is a note to let you know that I've just added the patch titled
ceph: only dirty ITER_IOVEC pages for direct read
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ceph-only-dirty-iter_iovec-pages-for-direct-read.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 85784f9395987a422fa04263e7c0fb13da11eb5c Mon Sep 17 00:00:00 2001
From: "Yan, Zheng" <zyan(a)redhat.com>
Date: Fri, 16 Mar 2018 11:22:29 +0800
Subject: ceph: only dirty ITER_IOVEC pages for direct read
From: Yan, Zheng <zyan(a)redhat.com>
commit 85784f9395987a422fa04263e7c0fb13da11eb5c upstream.
If a page is already locked, attempting to dirty it leads to a deadlock
in lock_page(). This is what currently happens to ITER_BVEC pages when
a dio-enabled loop device is backed by ceph:
$ losetup --direct-io /dev/loop0 /mnt/cephfs/img
$ xfs_io -c 'pread 0 4k' /dev/loop0
Follow other file systems and only dirty ITER_IOVEC pages.
Cc: stable(a)kernel.org
Signed-off-by: "Yan, Zheng" <zyan(a)redhat.com>
Reviewed-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ceph/file.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -635,7 +635,8 @@ static ssize_t ceph_sync_read(struct kio
struct ceph_aio_request {
struct kiocb *iocb;
size_t total_len;
- int write;
+ bool write;
+ bool should_dirty;
int error;
struct list_head osd_reqs;
unsigned num_reqs;
@@ -745,7 +746,7 @@ static void ceph_aio_complete_req(struct
}
}
- ceph_put_page_vector(osd_data->pages, num_pages, !aio_req->write);
+ ceph_put_page_vector(osd_data->pages, num_pages, aio_req->should_dirty);
ceph_osdc_put_request(req);
if (rc < 0)
@@ -842,6 +843,7 @@ ceph_direct_read_write(struct kiocb *ioc
size_t count = iov_iter_count(iter);
loff_t pos = iocb->ki_pos;
bool write = iov_iter_rw(iter) == WRITE;
+ bool should_dirty = !write && iter_is_iovec(iter);
if (write && ceph_snap(file_inode(file)) != CEPH_NOSNAP)
return -EROFS;
@@ -909,6 +911,7 @@ ceph_direct_read_write(struct kiocb *ioc
if (aio_req) {
aio_req->iocb = iocb;
aio_req->write = write;
+ aio_req->should_dirty = should_dirty;
INIT_LIST_HEAD(&aio_req->osd_reqs);
if (write) {
aio_req->mtime = mtime;
@@ -966,7 +969,7 @@ ceph_direct_read_write(struct kiocb *ioc
len = ret;
}
- ceph_put_page_vector(pages, num_pages, !write);
+ ceph_put_page_vector(pages, num_pages, should_dirty);
ceph_osdc_put_request(req);
if (ret < 0)
Patches currently in stable-queue which might be from zyan(a)redhat.com are
queue-4.15/ceph-only-dirty-iter_iovec-pages-for-direct-read.patch