Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1632692 > unrolled thread
| Started by | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| First post | 2017-04-28 11:00 +0200 |
| Last post | 2017-04-29 09:50 +0200 |
| Articles | 8 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH 4.4 00/17] 4.4.65-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-28 11:00 +0200
[PATCH 4.4 03/17] tipc: re-enable compensation for socket receive buffer double counting Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-28 11:00 +0200
[PATCH 4.4 12/17] netfilter: nfnetlink: correctly validate length of batch messages Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-28 11:00 +0200
[PATCH 4.4 04/17] tipc: correct error in node fsm Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-28 11:00 +0200
Re: [PATCH 4.4 00/17] 4.4.65-stable review Guenter Roeck <linux@roeck-us.net> - 2017-04-28 20:50 +0200
Re: [PATCH 4.4 00/17] 4.4.65-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-29 09:50 +0200
Re: [PATCH 4.4 00/17] 4.4.65-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-04-28 21:20 +0200
Re: [PATCH 4.4 00/17] 4.4.65-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-29 09:50 +0200
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2017-04-28 11:00 +0200 |
| Subject | [PATCH 4.4 00/17] 4.4.65-stable review |
| Message-ID | <tB9Bv-4Ua-9@gated-at.bofh.it> |
This is the start of the stable review cycle for the 4.4.65 release.
There are 17 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Apr 30 08:28:47 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.65-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 4.4.65-rc1
Peter Zijlstra <peterz@infradead.org>
perf/core: Fix concurrent sys_perf_event_open() vs. 'move_group' race
Eric Dumazet <edumazet@google.com>
ping: implement proper locking
EunTaik Lee <eun.taik.lee@samsung.com>
staging/android/ion : fix a race condition in the ion driver
Vlad Tsyrklevich <vlad@tsyrklevich.net>
vfio/pci: Fix integer overflows, bitmask check
Michal Kubeček <mkubecek@suse.cz>
tipc: check minimum bearer MTU
Phil Turnbull <phil.turnbull@oracle.com>
netfilter: nfnetlink: correctly validate length of batch messages
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
xc2028: avoid use after free
Eric W. Biederman <ebiederm@xmission.com>
mnt: Add a per mount namespace limit on the number of mounts
Jon Paul Maloy <jon.maloy@ericsson.com>
tipc: fix socket timer deadlock
Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
tipc: fix random link resets while adding a second bearer
Arnd Bergmann <arnd@arndb.de>
gfs2: avoid uninitialized variable warning
Arnd Bergmann <arnd@arndb.de>
hostap: avoid uninitialized variable use in hfa384x_get_rid
Arnd Bergmann <arnd@arndb.de>
tty: nozomi: avoid a harmless gcc warning
Jon Paul Maloy <jon.maloy@ericsson.com>
tipc: correct error in node fsm
Jon Paul Maloy <jon.maloy@ericsson.com>
tipc: re-enable compensation for socket receive buffer double counting
Erik Hugne <erik.hugne@gmail.com>
tipc: make dist queue pernet
Richard Alpe <richard.alpe@ericsson.com>
tipc: make sure IPv6 header fits in skb headroom
-------------
Diffstat:
Documentation/sysctl/fs.txt | 7 ++++
Makefile | 4 +--
drivers/media/tuners/tuner-xc2028.c | 3 +-
drivers/net/wireless/hostap/hostap_hw.c | 15 ++++++---
drivers/staging/android/ion/ion.c | 55 +++++++++++++++++++++++--------
drivers/tty/nozomi.c | 2 +-
drivers/vfio/pci/vfio_pci.c | 33 ++++++++++++-------
drivers/vfio/pci/vfio_pci_intrs.c | 2 +-
fs/gfs2/dir.c | 4 +--
fs/mount.h | 2 ++
fs/namespace.c | 50 ++++++++++++++++++++++++++++-
fs/pnode.c | 2 +-
fs/pnode.h | 1 +
include/linux/mount.h | 2 ++
kernel/events/core.c | 57 ++++++++++++++++++++++++++++++---
kernel/sysctl.c | 9 ++++++
net/ipv4/ping.c | 5 +--
net/netfilter/nfnetlink.c | 10 +++---
net/tipc/bearer.c | 13 ++++++--
net/tipc/bearer.h | 13 ++++++++
net/tipc/core.c | 1 +
net/tipc/core.h | 3 ++
net/tipc/name_distr.c | 24 +++++++-------
net/tipc/node.c | 4 +--
net/tipc/socket.c | 56 ++++++++++++++++++++++++--------
net/tipc/udp_media.c | 7 +++-
26 files changed, 305 insertions(+), 79 deletions(-)
[toc] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2017-04-28 11:00 +0200 |
| Subject | [PATCH 4.4 03/17] tipc: re-enable compensation for socket receive buffer double counting |
| Message-ID | <tB9US-53z-31@gated-at.bofh.it> |
| In reply to | #1632692 |
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jon Paul Maloy <jon.maloy@ericsson.com>
commit 7c8bcfb1255fe9d929c227d67bdcd84430fd200b upstream.
In the refactoring commit d570d86497ee ("tipc: enqueue arrived buffers
in socket in separate function") we did by accident replace the test
if (sk->sk_backlog.len == 0)
atomic_set(&tsk->dupl_rcvcnt, 0);
with
if (sk->sk_backlog.len)
atomic_set(&tsk->dupl_rcvcnt, 0);
This effectively disables the compensation we have for the double
receive buffer accounting that occurs temporarily when buffers are
moved from the backlog to the socket receive queue. Until now, this
has gone unnoticed because of the large receive buffer limits we are
applying, but becomes indispensable when we reduce this buffer limit
later in this series.
We now fix this by inverting the mentioned condition.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/tipc/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1755,7 +1755,7 @@ static void tipc_sk_enqueue(struct sk_bu
/* Try backlog, compensating for double-counted bytes */
dcnt = &tipc_sk(sk)->dupl_rcvcnt;
- if (sk->sk_backlog.len)
+ if (!sk->sk_backlog.len)
atomic_set(dcnt, 0);
lim = rcvbuf_limit(sk, skb) + atomic_read(dcnt);
if (likely(!sk_add_backlog(sk, skb, lim)))
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2017-04-28 11:00 +0200 |
| Subject | [PATCH 4.4 12/17] netfilter: nfnetlink: correctly validate length of batch messages |
| Message-ID | <tB9UT-53z-39@gated-at.bofh.it> |
| In reply to | #1632692 |
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Phil Turnbull <phil.turnbull@oracle.com>
commit c58d6c93680f28ac58984af61d0a7ebf4319c241 upstream.
If nlh->nlmsg_len is zero then an infinite loop is triggered because
'skb_pull(skb, msglen);' pulls zero bytes.
The calculation in nlmsg_len() underflows if 'nlh->nlmsg_len <
NLMSG_HDRLEN' which bypasses the length validation and will later
trigger an out-of-bound read.
If the length validation does fail then the malformed batch message is
copied back to userspace. However, we cannot do this because the
nlh->nlmsg_len can be invalid. This leads to an out-of-bounds read in
netlink_ack:
[ 41.455421] ==================================================================
[ 41.456431] BUG: KASAN: slab-out-of-bounds in memcpy+0x1d/0x40 at addr ffff880119e79340
[ 41.456431] Read of size 4294967280 by task a.out/987
[ 41.456431] =============================================================================
[ 41.456431] BUG kmalloc-512 (Not tainted): kasan: bad access detected
[ 41.456431] -----------------------------------------------------------------------------
...
[ 41.456431] Bytes b4 ffff880119e79310: 00 00 00 00 d5 03 00 00 b0 fb fe ff 00 00 00 00 ................
[ 41.456431] Object ffff880119e79320: 20 00 00 00 10 00 05 00 00 00 00 00 00 00 00 00 ...............
[ 41.456431] Object ffff880119e79330: 14 00 0a 00 01 03 fc 40 45 56 11 22 33 10 00 05 .......@EV."3...
[ 41.456431] Object ffff880119e79340: f0 ff ff ff 88 99 aa bb 00 14 00 0a 00 06 fe fb ................
^^ start of batch nlmsg with
nlmsg_len=4294967280
...
[ 41.456431] Memory state around the buggy address:
[ 41.456431] ffff880119e79400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 41.456431] ffff880119e79480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 41.456431] >ffff880119e79500: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
[ 41.456431] ^
[ 41.456431] ffff880119e79580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 41.456431] ffff880119e79600: fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb fb
[ 41.456431] ==================================================================
Fix this with better validation of nlh->nlmsg_len and by setting
NFNL_BATCH_FAILURE if any batch message fails length validation.
CAP_NET_ADMIN is required to trigger the bugs.
Fixes: 9ea2aa8b7dba ("netfilter: nfnetlink: validate nfnetlink header from batch")
Signed-off-by: Phil Turnbull <phil.turnbull@oracle.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netfilter/nfnetlink.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -326,10 +326,12 @@ replay:
nlh = nlmsg_hdr(skb);
err = 0;
- if (nlmsg_len(nlh) < sizeof(struct nfgenmsg) ||
- skb->len < nlh->nlmsg_len) {
- err = -EINVAL;
- goto ack;
+ if (nlh->nlmsg_len < NLMSG_HDRLEN ||
+ skb->len < nlh->nlmsg_len ||
+ nlmsg_len(nlh) < sizeof(struct nfgenmsg)) {
+ nfnl_err_reset(&err_list);
+ status |= NFNL_BATCH_FAILURE;
+ goto done;
}
/* Only requests are handled by the kernel */
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2017-04-28 11:00 +0200 |
| Subject | [PATCH 4.4 04/17] tipc: correct error in node fsm |
| Message-ID | <tB9UT-53z-41@gated-at.bofh.it> |
| In reply to | #1632692 |
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jon Paul Maloy <jon.maloy@ericsson.com>
commit c4282ca76c5b81ed73ef4c5eb5c07ee397e51642 upstream.
commit 88e8ac7000dc ("tipc: reduce transmission rate of reset messages
when link is down") revealed a flaw in the node FSM, as defined in
the log of commit 66996b6c47ed ("tipc: extend node FSM").
We see the following scenario:
1: Node B receives a RESET message from node A before its link endpoint
is fully up, i.e., the node FSM is in state SELF_UP_PEER_COMING. This
event will not change the node FSM state, but the (distinct) link FSM
will move to state RESETTING.
2: As an effect of the previous event, the local endpoint on B will
declare node A lost, and post the event SELF_DOWN to the its node
FSM. This moves the FSM state to SELF_DOWN_PEER_LEAVING, meaning
that no messages will be accepted from A until it receives another
RESET message that confirms that A's endpoint has been reset. This
is wasteful, since we know this as a fact already from the first
received RESET, but worse is that the link instance's FSM has not
wasted this information, but instead moved on to state ESTABLISHING,
meaning that it repeatedly sends out ACTIVATE messages to the reset
peer A.
3: Node A will receive one of the ACTIVATE messages, move its link FSM
to state ESTABLISHED, and start repeatedly sending out STATE messages
to node B.
4: Node B will consistently drop these messages, since it can only accept
accept a RESET according to its node FSM.
5: After four lost STATE messages node A will reset its link and start
repeatedly sending out RESET messages to B.
6: Because of the reduced send rate for RESET messages, it is very
likely that A will receive an ACTIVATE (which is sent out at a much
higher frequency) before it gets the chance to send a RESET, and A
may hence quickly move back to state ESTABLISHED and continue sending
out STATE messages, which will again be dropped by B.
7: GOTO 5.
8: After having repeated the cycle 5-7 a number of times, node A will
by chance get in between with sending a RESET, and the situation is
resolved.
Unfortunately, we have seen that it may take a substantial amount of
time before this vicious loop is broken, sometimes in the order of
minutes.
We correct this by making a small correction to the node FSM: When a
node in state SELF_UP_PEER_COMING receives a SELF_DOWN event, it now
moves directly back to state SELF_DOWN_PEER_DOWN, instead of as now
SELF_DOWN_PEER_LEAVING. This is logically consistent, since we don't
need to wait for RESET confirmation from of an endpoint that we alread
know has been reset. It also means that node B in the scenario above
will not be dropping incoming STATE messages, and the link can come up
immediately.
Finally, a symmetry comparison reveals that the FSM has a similar
error when receiving the event PEER_DOWN in state PEER_UP_SELF_COMING.
Instead of moving to PERR_DOWN_SELF_LEAVING, it should move directly
to SELF_DOWN_PEER_DOWN. Although we have never seen any negative effect
of this logical error, we choose fix this one, too.
The node FSM looks as follows after those changes:
+----------------------------------------+
| PEER_DOWN_EVT|
| |
+------------------------+----------------+ |
|SELF_DOWN_EVT | | |
| | | |
| +-----------+ +-----------+ |
| |NODE_ | |NODE_ | |
| +----------|FAILINGOVER|<---------|SYNCHING |-----------+ |
| |SELF_ +-----------+ FAILOVER_+-----------+ PEER_ | |
| |DOWN_EVT | A BEGIN_EVT A | DOWN_EVT| |
| | | | | | | |
| | | | | | | |
| | |FAILOVER_ |FAILOVER_ |SYNCH_ |SYNCH_ | |
| | |END_EVT |BEGIN_EVT |BEGIN_EVT|END_EVT | |
| | | | | | | |
| | | | | | | |
| | | +--------------+ | | |
| | +-------->| SELF_UP_ |<-------+ | |
| | +-----------------| PEER_UP |----------------+ | |
| | |SELF_DOWN_EVT +--------------+ PEER_DOWN_EVT| | |
| | | A A | | |
| | | | | | | |
| | | PEER_UP_EVT| |SELF_UP_EVT | | |
| | | | | | | |
V V V | | V V V
+------------+ +-----------+ +-----------+ +------------+
|SELF_DOWN_ | |SELF_UP_ | |PEER_UP_ | |PEER_DOWN |
|PEER_LEAVING| |PEER_COMING| |SELF_COMING| |SELF_LEAVING|
+------------+ +-----------+ +-----------+ +------------+
| | A A | |
| | | | | |
| SELF_ | |SELF_ |PEER_ |PEER_ |
| DOWN_EVT| |UP_EVT |UP_EVT |DOWN_EVT |
| | | | | |
| | | | | |
| | +--------------+ | |
|PEER_DOWN_EVT +--->| SELF_DOWN_ |<---+ SELF_DOWN_EVT|
+------------------->| PEER_DOWN |<--------------------+
+--------------+
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/tipc/node.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -728,7 +728,7 @@ static void tipc_node_fsm_evt(struct tip
state = SELF_UP_PEER_UP;
break;
case SELF_LOST_CONTACT_EVT:
- state = SELF_DOWN_PEER_LEAVING;
+ state = SELF_DOWN_PEER_DOWN;
break;
case SELF_ESTABL_CONTACT_EVT:
case PEER_LOST_CONTACT_EVT:
@@ -747,7 +747,7 @@ static void tipc_node_fsm_evt(struct tip
state = SELF_UP_PEER_UP;
break;
case PEER_LOST_CONTACT_EVT:
- state = SELF_LEAVING_PEER_DOWN;
+ state = SELF_DOWN_PEER_DOWN;
break;
case SELF_LOST_CONTACT_EVT:
case PEER_ESTABL_CONTACT_EVT:
[toc] | [prev] | [next] | [standalone]
| From | Guenter Roeck <linux@roeck-us.net> |
|---|---|
| Date | 2017-04-28 20:50 +0200 |
| Message-ID | <tBj7P-2VD-7@gated-at.bofh.it> |
| In reply to | #1632692 |
On Fri, Apr 28, 2017 at 10:30:13AM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.65 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Apr 30 08:28:47 UTC 2017. > Anything received after that time might be too late. > Build results: total: 149 pass: 149 fail: 0 Qemu test results: total: 122 pass: 122 fail: 0 Details are available at http://kerneltests.org/builders. Guenter
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2017-04-29 09:50 +0200 |
| Message-ID | <tBviH-3qf-31@gated-at.bofh.it> |
| In reply to | #1633085 |
On Fri, Apr 28, 2017 at 11:46:06AM -0700, Guenter Roeck wrote: > On Fri, Apr 28, 2017 at 10:30:13AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.65 release. > > There are 17 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Apr 30 08:28:47 UTC 2017. > > Anything received after that time might be too late. > > > > Build results: > total: 149 pass: 149 fail: 0 > Qemu test results: > total: 122 pass: 122 fail: 0 > > Details are available at http://kerneltests.org/builders. Thanks for testing both of these and letting me know. greg k-h
[toc] | [prev] | [next] | [standalone]
| From | Shuah Khan <shuahkh@osg.samsung.com> |
|---|---|
| Date | 2017-04-28 21:20 +0200 |
| Message-ID | <tBjAR-3oJ-1@gated-at.bofh.it> |
| In reply to | #1632692 |
On 04/28/2017 02:30 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.65 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Apr 30 08:28:47 UTC 2017. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.65-rc1.gz > or in the git tree and branch at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2017-04-29 09:50 +0200 |
| Message-ID | <tBviH-3qf-35@gated-at.bofh.it> |
| In reply to | #1633094 |
On Fri, Apr 28, 2017 at 01:18:18PM -0600, Shuah Khan wrote: > On 04/28/2017 02:30 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.65 release. > > There are 17 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Apr 30 08:28:47 UTC 2017. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.65-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing both of these and letting me know. greg k-h
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web