This is a note to let you know that I've just added the patch titled
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
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:
security-keys-add-config_keys_compat-to-kconfig.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 47b2c3fff4932e6fc17ce13d51a43c6969714e20 Mon Sep 17 00:00:00 2001
From: Bilal Amarni <bilal.amarni(a)gmail.com>
Date: Thu, 8 Jun 2017 14:47:26 +0100
Subject: security/keys: add CONFIG_KEYS_COMPAT to Kconfig
From: Bilal Amarni <bilal.amarni(a)gmail.com>
commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 upstream.
CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for
several 64-bit architectures : mips, parisc, tile.
At the moment and for those architectures, calling in 32-bit userspace the
keyctl syscall would return an ENOSYS error.
This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to
make sure the compatibility wrapper is registered by default for any 64-bit
architecture as long as it is configured with CONFIG_COMPAT.
[DH: Modified to remove arm64 compat enablement also as requested by Eric
Biggers]
Signed-off-by: Bilal Amarni <bilal.amarni(a)gmail.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Cc: James Cowgill <james.cowgill(a)mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/Kconfig | 5 -----
arch/s390/Kconfig | 3 ---
arch/sparc/Kconfig | 3 ---
arch/x86/Kconfig | 4 ----
security/keys/Kconfig | 4 ++++
5 files changed, 4 insertions(+), 15 deletions(-)
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1070,11 +1070,6 @@ source "arch/powerpc/Kconfig.debug"
source "security/Kconfig"
-config KEYS_COMPAT
- bool
- depends on COMPAT && KEYS
- default y
-
source "crypto/Kconfig"
config PPC_LIB_RHEAP
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -332,9 +332,6 @@ config COMPAT
config SYSVIPC_COMPAT
def_bool y if COMPAT && SYSVIPC
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
config SMP
def_bool y
prompt "Symmetric multi-processing support"
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -542,9 +542,6 @@ config SYSVIPC_COMPAT
depends on COMPAT && SYSVIPC
default y
-config KEYS_COMPAT
- def_bool y if COMPAT && KEYS
-
endmenu
source "net/Kconfig"
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2471,10 +2471,6 @@ config COMPAT_FOR_U64_ALIGNMENT
config SYSVIPC_COMPAT
def_bool y
depends on SYSVIPC
-
-config KEYS_COMPAT
- def_bool y
- depends on KEYS
endif
endmenu
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -20,6 +20,10 @@ config KEYS
If you are unsure as to whether this is required, answer N.
+config KEYS_COMPAT
+ def_bool y
+ depends on COMPAT && KEYS
+
config PERSISTENT_KEYRINGS
bool "Enable register of persistent per-UID keyrings"
depends on KEYS
Patches currently in stable-queue which might be from bilal.amarni(a)gmail.com are
queue-3.18/security-keys-add-config_keys_compat-to-kconfig.patch
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Greg-KH,
Here are two target patches for v4.4.y stable, the first of which
did not originally include a stable CC, and the latter did not apply
due to a minor context change.
The series has been cut against v4.4.98. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Nicholas Bellinger (1):
target: Fix node_acl demo-mode + uncached dynamic shutdown regression
drivers/target/iscsi/iscsi_target.c | 19 +++++++------------
drivers/target/target_core_tpg.c | 4 ++--
drivers/target/target_core_transport.c | 4 ++--
include/target/target_core_base.h | 1 +
4 files changed, 12 insertions(+), 16 deletions(-)
--
1.8.5.3
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Hi Greg-KH,
Here are two target patches for v4.9.y stable, the first of which
did not originally include a stable CC, and the latter did not apply
due to a minor context change.
The series has been cut against v4.9.62. Please apply at your earliest
convenience.
Thank you,
--nab
Bart Van Assche (1):
target/iscsi: Fix iSCSI task reassignment handling
Nicholas Bellinger (1):
qla2xxx: Fix incorrect tcm_qla2xxx_free_cmd use during TMR ABORT (v2)
drivers/scsi/qla2xxx/tcm_qla2xxx.c | 33 ---------------------------------
drivers/target/iscsi/iscsi_target.c | 19 +++++++------------
include/target/target_core_base.h | 1 +
3 files changed, 8 insertions(+), 45 deletions(-)
--
1.8.5.3
Hello,
Upstream commit d01332f1acacc0cb43a61f4244dd2b846d4cd585 ("tipc: fix
link attribute propagation bug") fixes a tipc oops that can be triggered
from user space, we want it also in 4.4-stable. I've backported the
patch, as it does not apply as-is to 4.4.
Richard Alpe (1):
tipc: fix link attribute propagation bug
net/tipc/link.c | 28 ++++++----------------------
net/tipc/link.h | 1 -
2 files changed, 6 insertions(+), 23 deletions(-)
--
2.13.6
Hi,
Is it possible to apply this commit to the stable trees before 4.12?
commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20
Author: Bilal Amarni <bilal.amarni(a)gmail.com>
Date: Thu Jun 8 14:47:26 2017 +0100
security/keys: add CONFIG_KEYS_COMPAT to Kconfig
In commit 20f06ed9f61a ("KEYS: 64-bit MIPS needs to use
compat_sys_keyctl for 32-bit userspace"), the keyctl syscall for 32-bit
MIPS was "fixed" to point at compat_sys_keyctl instead of sys_keyctl.
Unfortunately this caused the syscall to always return ENOSYS because
CONFIG_KEYS_COMPAT was not enabled on MIPS. Instead of fixing this by
manually by enabling KEYS_COMPAT in the MIPS Kconfig, I think applying
the above commit is a better.
Thanks,
James
These two patches get rid of rhashtable the conversion.
First patch is an implicit dependency, rhlist remove interface
is a no-op in case element is not yet in the table, but hlist_del_rcu()
must only be called for conntracks that already have been inserted.
Second patch is the actual revert.
2017-10-30 10:19 GMT+01:00 Daniel Vetter <daniel(a)ffwll.ch>:
> On Tue, Oct 24, 2017 at 11:01:32AM +0200, Benjamin Gaignard wrote:
>> 2017-10-23 17:25 GMT+02:00 Ville Syrjala <ville.syrjala(a)linux.intel.com>:
>> > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
>> >
>> > Since commit 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
>> > even drivers that don't implement accurate vblank timestamps will end
>> > up using drm_crtc_accurate_vblank_count(). That leads to a WARN every
>> > time drm_crtc_arm_vblank_event() gets called. The could be as often
>> > as every frame for each active crtc.
>> >
>> > Considering drm_crtc_accurate_vblank_count() is never any worse than
>> > the drm_vblank_count() we used previously, let's just skip the WARN
>> > unless DRM_UT_VBL is enabled. That way people won't be bothered by
>> > this unless they're debugging vblank code. And let's also change it
>> > to WARN_ONCE() so that even when you're debugging vblank code you
>> > won't get drowned by constant WARNs.
>> >
>> > Cc: stable(a)vger.kernel.org
>> > Cc: Daniel Vetter <daniel(a)ffwll.ch>
>> > Cc: "Szyprowski, Marek" <m.szyprowski(a)samsung.com>
>> > Cc: Andrzej Hajda <a.hajda(a)samsung.com>
>> > Reported-by: Andrzej Hajda <a.hajda(a)samsung.com>
>> > Fixes: 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
>> > Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
>>
>> I have tested it on sti and stm driver, it fix the problem, thanks.
>>
>> Acked-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
>>
>> > ---
>> > drivers/gpu/drm/drm_vblank.c | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
>> > index 13722c373a6a..c81c297995c6 100644
>> > --- a/drivers/gpu/drm/drm_vblank.c
>> > +++ b/drivers/gpu/drm/drm_vblank.c
>> > @@ -299,8 +299,8 @@ u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
>> > u32 vblank;
>> > unsigned long flags;
>> >
>> > - WARN(!dev->driver->get_vblank_timestamp,
>> > - "This function requires support for accurate vblank timestamps.");
>> > + WARN_ONCE(drm_debug & DRM_UT_VBL && !dev->driver->get_vblank_timestamp,
>> > + "This function requires support for accurate vblank timestamps.");
>
> Somewhat a bikeshed, but if we e.g. enable debugging in a CI or piglit
> run, then this could change the results. I'd go with a if ()
> DRM_DEBUG_VBLANK. Either way:
>
> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
>
Does something is missing to merge this fix in drm-misc ?
Without it I got warning at each frame.
Benjamin
>> >
>> > spin_lock_irqsave(&dev->vblank_time_lock, flags);
>> >
>> > --
>> > 2.13.6
>> >
>> > _______________________________________________
>> > dri-devel mailing list
>> > dri-devel(a)lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel(a)lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
This is a note to let you know that I've just added the patch titled
ipv6: flowlabel: do not leave opt->tot_len with garbage
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:
ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.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 foo@baz Thu Nov 16 15:49:43 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Sat, 21 Oct 2017 12:26:23 -0700
Subject: ipv6: flowlabel: do not leave opt->tot_len with garbage
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 864e2a1f8aac05effac6063ce316b480facb46ff ]
When syzkaller team brought us a C repro for the crash [1] that
had been reported many times in the past, I finally could find
the root cause.
If FlowLabel info is merged by fl6_merge_options(), we leave
part of the opt_space storage provided by udp/raw/l2tp with random value
in opt_space.tot_len, unless a control message was provided at sendmsg()
time.
Then ip6_setup_cork() would use this random value to perform a kzalloc()
call. Undefined behavior and crashes.
Fix is to properly set tot_len in fl6_merge_options()
At the same time, we can also avoid consuming memory and cpu cycles
to clear it, if every option is copied via a kmemdup(). This is the
change in ip6_setup_cork().
[1]
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 6613 Comm: syz-executor0 Not tainted 4.14.0-rc4+ #127
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff8801cb64a100 task.stack: ffff8801cc350000
RIP: 0010:ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168
RSP: 0018:ffff8801cc357550 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: ffff8801cc357748 RCX: 0000000000000010
RDX: 0000000000000002 RSI: ffffffff842bd1d9 RDI: 0000000000000014
RBP: ffff8801cc357620 R08: ffff8801cb17f380 R09: ffff8801cc357b10
R10: ffff8801cb64a100 R11: 0000000000000000 R12: ffff8801cc357ab0
R13: ffff8801cc357b10 R14: 0000000000000000 R15: ffff8801c3bbf0c0
FS: 00007f9c5c459700(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020324000 CR3: 00000001d1cf2000 CR4: 00000000001406f0
DR0: 0000000020001010 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Call Trace:
ip6_make_skb+0x282/0x530 net/ipv6/ip6_output.c:1729
udpv6_sendmsg+0x2769/0x3380 net/ipv6/udp.c:1340
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
SYSC_sendto+0x358/0x5a0 net/socket.c:1750
SyS_sendto+0x40/0x50 net/socket.c:1718
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4520a9
RSP: 002b:00007f9c5c458c08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 00000000004520a9
RDX: 0000000000000001 RSI: 0000000020fd1000 RDI: 0000000000000016
RBP: 0000000000000086 R08: 0000000020e0afe4 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004bb1ee
R13: 00000000ffffffff R14: 0000000000000016 R15: 0000000000000029
Code: e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ea 0f 00 00 48 8d 79 04 48 b8 00 00 00 00 00 fc ff df 45 8b 74 24 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
RIP: ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168 RSP: ffff8801cc357550
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_output.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -316,6 +316,7 @@ struct ipv6_txoptions *fl6_merge_options
}
opt_space->dst1opt = fopt->dst1opt;
opt_space->opt_flen = fopt->opt_flen;
+ opt_space->tot_len = fopt->tot_len;
return opt_space;
}
EXPORT_SYMBOL_GPL(fl6_merge_options);
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1177,11 +1177,11 @@ int ip6_append_data(struct sock *sk, int
if (WARN_ON(np->cork.opt))
return -EINVAL;
- np->cork.opt = kzalloc(opt->tot_len, sk->sk_allocation);
+ np->cork.opt = kzalloc(sizeof(*opt), sk->sk_allocation);
if (unlikely(np->cork.opt == NULL))
return -ENOBUFS;
- np->cork.opt->tot_len = opt->tot_len;
+ np->cork.opt->tot_len = sizeof(*opt);
np->cork.opt->opt_flen = opt->opt_flen;
np->cork.opt->opt_nflen = opt->opt_nflen;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-3.18/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-3.18/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-3.18/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-3.18/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
ipip: only increase err_count for some certain type icmp in ipip_err
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:
ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.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 foo@baz Thu Nov 16 15:49:43 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Thu, 26 Oct 2017 19:19:56 +0800
Subject: ipip: only increase err_count for some certain type icmp in ipip_err
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit f3594f0a7ea36661d7fd942facd7f31a64245f1a ]
t->err_count is used to count the link failure on tunnel and an err
will be reported to user socket in tx path if t->err_count is not 0.
udp socket could even return EHOSTUNREACH to users.
Since commit fd58156e456d ("IPIP: Use ip-tunneling code.") removed
the 'switch check' for icmp type in ipip_err(), err_count would be
increased by the icmp packet with ICMP_EXC_FRAGTIME code. an link
failure would be reported out due to this.
In Jianlin's case, when receiving ICMP_EXC_FRAGTIME a icmp packet,
udp netperf failed with the err:
send_data: data send error: No route to host (errno 113)
We expect this error reported from tunnel to socket when receiving
some certain type icmp, but not ICMP_EXC_FRAGTIME, ICMP_SR_FAILED
or ICMP_PARAMETERPROB ones.
This patch is to bring 'switch check' for icmp type back to ipip_err
so that it only reports link failure for the right type icmp, just as
in ipgre_err() and ipip6_err().
Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ipip.c | 59 +++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 42 insertions(+), 17 deletions(-)
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -128,43 +128,68 @@ static struct rtnl_link_ops ipip_link_op
static int ipip_err(struct sk_buff *skb, u32 info)
{
-
-/* All the routers (except for Linux) return only
- 8 bytes of packet payload. It means, that precise relaying of
- ICMP in the real Internet is absolutely infeasible.
- */
+ /* All the routers (except for Linux) return only
+ 8 bytes of packet payload. It means, that precise relaying of
+ ICMP in the real Internet is absolutely infeasible.
+ */
struct net *net = dev_net(skb->dev);
struct ip_tunnel_net *itn = net_generic(net, ipip_net_id);
const struct iphdr *iph = (const struct iphdr *)skb->data;
- struct ip_tunnel *t;
- int err;
const int type = icmp_hdr(skb)->type;
const int code = icmp_hdr(skb)->code;
+ struct ip_tunnel *t;
+ int err = 0;
+
+ switch (type) {
+ case ICMP_DEST_UNREACH:
+ switch (code) {
+ case ICMP_SR_FAILED:
+ /* Impossible event. */
+ goto out;
+ default:
+ /* All others are translated to HOST_UNREACH.
+ * rfc2003 contains "deep thoughts" about NET_UNREACH,
+ * I believe they are just ether pollution. --ANK
+ */
+ break;
+ }
+ break;
+
+ case ICMP_TIME_EXCEEDED:
+ if (code != ICMP_EXC_TTL)
+ goto out;
+ break;
+
+ case ICMP_REDIRECT:
+ break;
+
+ default:
+ goto out;
+ }
- err = -ENOENT;
t = ip_tunnel_lookup(itn, skb->dev->ifindex, TUNNEL_NO_KEY,
iph->daddr, iph->saddr, 0);
- if (t == NULL)
+ if (!t) {
+ err = -ENOENT;
goto out;
+ }
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) {
- ipv4_update_pmtu(skb, dev_net(skb->dev), info,
- t->parms.link, 0, IPPROTO_IPIP, 0);
- err = 0;
+ ipv4_update_pmtu(skb, net, info, t->parms.link, 0,
+ iph->protocol, 0);
goto out;
}
if (type == ICMP_REDIRECT) {
- ipv4_redirect(skb, dev_net(skb->dev), t->parms.link, 0,
- IPPROTO_IPIP, 0);
- err = 0;
+ ipv4_redirect(skb, net, t->parms.link, 0, iph->protocol, 0);
goto out;
}
- if (t->parms.iph.daddr == 0)
+ if (t->parms.iph.daddr == 0) {
+ err = -ENOENT;
goto out;
+ }
- err = 0;
if (t->parms.iph.ttl == 0 && type == ICMP_TIME_EXCEEDED)
goto out;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-3.18/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-3.18/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-3.18/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch