This is a note to let you know that I've just added the patch titled
kcov: detect double association with a single task
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:
kcov-detect-double-association-with-a-single-task.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 a77660d231f8b3d84fd23ed482e0964f7aa546d6 Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 6 Feb 2018 15:40:28 -0800
Subject: kcov: detect double association with a single task
From: Dmitry Vyukov <dvyukov(a)google.com>
commit a77660d231f8b3d84fd23ed482e0964f7aa546d6 upstream.
Currently KCOV_ENABLE does not check if the current task is already
associated with another kcov descriptor. As the result it is possible
to associate a single task with more than one kcov descriptor, which
later leads to a memory leak of the old descriptor. This relation is
really meant to be one-to-one (task has only one back link).
Extend validation to detect such misuse.
Link: http://lkml.kernel.org/r/20180122082520.15716-1-dvyukov@google.com
Fixes: 5c9a8750a640 ("kernel: add kcov code coverage")
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: Shankara Pailoor <sp3485(a)columbia.edu>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: syzbot <syzkaller(a)googlegroups.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>
---
kernel/kcov.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/kcov.c
+++ b/kernel/kcov.c
@@ -225,9 +225,9 @@ static int kcov_ioctl_locked(struct kcov
if (unused != 0 || kcov->mode == KCOV_MODE_DISABLED ||
kcov->area == NULL)
return -EINVAL;
- if (kcov->t != NULL)
- return -EBUSY;
t = current;
+ if (kcov->t != NULL || t->kcov != NULL)
+ return -EBUSY;
/* Cache in task struct for performance. */
t->kcov_size = kcov->size;
t->kcov_area = kcov->area;
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.14/kvm-x86-check-input-paging-mode-when-cs.l-is-set.patch
queue-4.14/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.14/blktrace-fix-unlocked-registration-of-tracepoints.patch
queue-4.14/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.14/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.14/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
kcm: Only allow TCP sockets to be attached to a KCM mux
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:
kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.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 581e7226a5d43f629eb6399a121f85f6a15f81be Mon Sep 17 00:00:00 2001
From: Tom Herbert <tom(a)quantonium.net>
Date: Wed, 24 Jan 2018 12:35:40 -0800
Subject: kcm: Only allow TCP sockets to be attached to a KCM mux
From: Tom Herbert <tom(a)quantonium.net>
commit 581e7226a5d43f629eb6399a121f85f6a15f81be upstream.
TCP sockets for IPv4 and IPv6 that are not listeners or in closed
stated are allowed to be attached to a KCM mux.
Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
Reported-by: syzbot+8865eaff7f9acd593945(a)syzkaller.appspotmail.com
Signed-off-by: Tom Herbert <tom(a)quantonium.net>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/kcm/kcmsock.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1387,8 +1387,13 @@ static int kcm_attach(struct socket *soc
if (!csk)
return -EINVAL;
- /* We must prevent loops or risk deadlock ! */
- if (csk->sk_family == PF_KCM)
+ /* Only allow TCP sockets to be attached for now */
+ if ((csk->sk_family != AF_INET && csk->sk_family != AF_INET6) ||
+ csk->sk_protocol != IPPROTO_TCP)
+ return -EOPNOTSUPP;
+
+ /* Don't allow listeners or closed sockets */
+ if (csk->sk_state == TCP_LISTEN || csk->sk_state == TCP_CLOSE)
return -EOPNOTSUPP;
psock = kmem_cache_zalloc(kcm_psockp, GFP_KERNEL);
Patches currently in stable-queue which might be from tom(a)quantonium.net are
queue-4.14/kcm-check-if-sk_user_data-already-set-in-kcm_attach.patch
queue-4.14/kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.patch
This is a note to let you know that I've just added the patch titled
kcm: Check if sk_user_data already set in kcm_attach
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:
kcm-check-if-sk_user_data-already-set-in-kcm_attach.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 e5571240236c5652f3e079b1d5866716a7ad819c Mon Sep 17 00:00:00 2001
From: Tom Herbert <tom(a)quantonium.net>
Date: Wed, 24 Jan 2018 12:35:41 -0800
Subject: kcm: Check if sk_user_data already set in kcm_attach
From: Tom Herbert <tom(a)quantonium.net>
commit e5571240236c5652f3e079b1d5866716a7ad819c upstream.
This is needed to prevent sk_user_data being overwritten.
The check is done under the callback lock. This should prevent
a socket from being attached twice to a KCM mux. It also prevents
a socket from being attached for other use cases of sk_user_data
as long as the other cases set sk_user_data under the lock.
Followup work is needed to unify all the use cases of sk_user_data
to use the same locking.
Reported-by: syzbot+114b15f2be420a8886c3(a)syzkaller.appspotmail.com
Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
Signed-off-by: Tom Herbert <tom(a)quantonium.net>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/kcm/kcmsock.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1405,9 +1405,18 @@ static int kcm_attach(struct socket *soc
return err;
}
- sock_hold(csk);
-
write_lock_bh(&csk->sk_callback_lock);
+
+ /* Check if sk_user_data is aready by KCM or someone else.
+ * Must be done under lock to prevent race conditions.
+ */
+ if (csk->sk_user_data) {
+ write_unlock_bh(&csk->sk_callback_lock);
+ strp_done(&psock->strp);
+ kmem_cache_free(kcm_psockp, psock);
+ return -EALREADY;
+ }
+
psock->save_data_ready = csk->sk_data_ready;
psock->save_write_space = csk->sk_write_space;
psock->save_state_change = csk->sk_state_change;
@@ -1415,8 +1424,11 @@ static int kcm_attach(struct socket *soc
csk->sk_data_ready = psock_data_ready;
csk->sk_write_space = psock_write_space;
csk->sk_state_change = psock_state_change;
+
write_unlock_bh(&csk->sk_callback_lock);
+ sock_hold(csk);
+
/* Finished initialization, now add the psock to the MUX. */
spin_lock_bh(&mux->lock);
head = &mux->psocks;
Patches currently in stable-queue which might be from tom(a)quantonium.net are
queue-4.14/kcm-check-if-sk_user_data-already-set-in-kcm_attach.patch
queue-4.14/kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.patch
This is a note to let you know that I've just added the patch titled
esp: Fix GRO when the headers not fully in the linear part of the skb.
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:
esp-fix-gro-when-the-headers-not-fully-in-the-linear-part-of-the-skb.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 374d1b5a81f7f9cc5e7f095ac3d5aff3f6600376 Mon Sep 17 00:00:00 2001
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Fri, 5 Jan 2018 08:35:47 +0100
Subject: esp: Fix GRO when the headers not fully in the linear part of the skb.
From: Steffen Klassert <steffen.klassert(a)secunet.com>
commit 374d1b5a81f7f9cc5e7f095ac3d5aff3f6600376 upstream.
The GRO layer does not necessarily pull the complete headers
into the linear part of the skb, a part may remain on the
first page fragment. This can lead to a crash if we try to
pull the headers, so make sure we have them on the linear
part before pulling.
Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
Reported-by: syzbot+82bbd65569c49c6c0c4d(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/ipv4/esp4_offload.c | 3 ++-
net/ipv6/esp6_offload.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/net/ipv4/esp4_offload.c
+++ b/net/ipv4/esp4_offload.c
@@ -38,7 +38,8 @@ static struct sk_buff **esp4_gro_receive
__be32 spi;
int err;
- skb_pull(skb, offset);
+ if (!pskb_pull(skb, offset))
+ return NULL;
if ((err = xfrm_parse_spi(skb, IPPROTO_ESP, &spi, &seq)) != 0)
goto out;
--- a/net/ipv6/esp6_offload.c
+++ b/net/ipv6/esp6_offload.c
@@ -60,7 +60,8 @@ static struct sk_buff **esp6_gro_receive
int nhoff;
int err;
- skb_pull(skb, offset);
+ if (!pskb_pull(skb, offset))
+ return NULL;
if ((err = xfrm_parse_spi(skb, IPPROTO_ESP, &spi, &seq)) != 0)
goto out;
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-4.14/xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.patch
queue-4.14/xfrm-skip-policies-marked-as-dead-while-rehashing.patch
queue-4.14/xfrm-fix-rcu-usage-in-xfrm_get_type_offload.patch
queue-4.14/esp-fix-gro-when-the-headers-not-fully-in-the-linear-part-of-the-skb.patch
queue-4.14/xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.patch
queue-4.14/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
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:
drm-require-__gfp_nofail-for-the-legacy-drm_modeset_lock_all.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 d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Tue, 31 Oct 2017 11:55:35 +0000
Subject: drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Chris Wilson <chris(a)chris-wilson.co.uk>
commit d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 upstream.
To acquire all modeset locks requires a ww_ctx to be allocated. As this
is the legacy path and the allocation small, to reduce the changes
required (and complex untested error handling) to the legacy drivers, we
simply assume that the allocation succeeds. At present, it relies on the
too-small-to-fail rule, but syzbot found that by injecting a failure
here we would hit the WARN. Document that this allocation must succeed
with __GFP_NOFAIL.
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031115535.15166-1-chris@…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -88,7 +88,7 @@ void drm_modeset_lock_all(struct drm_dev
struct drm_modeset_acquire_ctx *ctx;
int ret;
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL | __GFP_NOFAIL);
if (WARN_ON(!ctx))
return;
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.14/drm-require-__gfp_nofail-for-the-legacy-drm_modeset_lock_all.patch
This is a note to let you know that I've just added the patch titled
dnotify: Handle errors from fsnotify_add_mark_locked() in fcntl_dirnotify()
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:
dnotify-handle-errors-from-fsnotify_add_mark_locked-in-fcntl_dirnotify.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 b3a0066005821acdc0cdb092cb72587182ab583f Mon Sep 17 00:00:00 2001
From: Jan Kara <jack(a)suse.cz>
Date: Tue, 31 Oct 2017 09:53:28 +0100
Subject: dnotify: Handle errors from fsnotify_add_mark_locked() in fcntl_dirnotify()
From: Jan Kara <jack(a)suse.cz>
commit b3a0066005821acdc0cdb092cb72587182ab583f upstream.
fsnotify_add_mark_locked() can fail but we do not check its return
value. This didn't matter before commit 9dd813c15b2c "fsnotify: Move
mark list head from object into dedicated structure" as none of possible
failures could happen for dnotify but after that commit -ENOMEM can be
returned. Handle this error properly in fcntl_dirnotify() as
otherwise we just hit BUG_ON(dn_mark->dn) in dnotify_free_mark().
Reviewed-by: Amir Goldstein <amir73il(a)gmail.com>
Reported-by: syzkaller
Fixes: 9dd813c15b2c101168808d4f5941a29985758973
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/notify/dnotify/dnotify.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/fs/notify/dnotify/dnotify.c
+++ b/fs/notify/dnotify/dnotify.c
@@ -319,7 +319,11 @@ int fcntl_dirnotify(int fd, struct file
dn_mark = container_of(fsn_mark, struct dnotify_mark, fsn_mark);
spin_lock(&fsn_mark->lock);
} else {
- fsnotify_add_mark_locked(new_fsn_mark, inode, NULL, 0);
+ error = fsnotify_add_mark_locked(new_fsn_mark, inode, NULL, 0);
+ if (error) {
+ mutex_unlock(&dnotify_group->mark_mutex);
+ goto out_err;
+ }
spin_lock(&new_fsn_mark->lock);
fsn_mark = new_fsn_mark;
dn_mark = new_dn_mark;
@@ -345,6 +349,7 @@ int fcntl_dirnotify(int fd, struct file
*/
if (dn_mark == new_dn_mark)
destroy = 1;
+ error = 0;
goto out;
}
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.14/dnotify-handle-errors-from-fsnotify_add_mark_locked-in-fcntl_dirnotify.patch
This is a note to let you know that I've just added the patch titled
cfg80211: check dev_set_name() return value
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:
cfg80211-check-dev_set_name-return-value.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 59b179b48ce2a6076448a44531242ac2b3f6cef2 Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Mon, 15 Jan 2018 09:58:27 +0100
Subject: cfg80211: check dev_set_name() return value
From: Johannes Berg <johannes.berg(a)intel.com>
commit 59b179b48ce2a6076448a44531242ac2b3f6cef2 upstream.
syzbot reported a warning from rfkill_alloc(), and after a while
I think that the reason is that it was doing fault injection and
the dev_set_name() failed, leaving the name NULL, and we didn't
check the return value and got to rfkill_alloc() with a NULL name.
Since we really don't want a NULL name, we ought to check the
return value.
Fixes: fb28ad35906a ("net: struct device - replace bus_id with dev_name(), dev_set_name()")
Reported-by: syzbot+1ddfb3357e1d7bb5b5d3(a)syzkaller.appspotmail.com
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/wireless/core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -439,6 +439,8 @@ struct wiphy *wiphy_new_nm(const struct
if (rv)
goto use_default_name;
} else {
+ int rv;
+
use_default_name:
/* NOTE: This is *probably* safe w/out holding rtnl because of
* the restrictions on phy names. Probably this call could
@@ -446,7 +448,11 @@ use_default_name:
* phyX. But, might should add some locking and check return
* value, and use a different name if this one exists?
*/
- dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
+ rv = dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
+ if (rv < 0) {
+ kfree(rdev);
+ return NULL;
+ }
}
INIT_LIST_HEAD(&rdev->wiphy.wdev_list);
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.14/cfg80211-check-dev_set_name-return-value.patch
queue-4.14/mac80211_hwsim-validate-number-of-different-channels.patch