Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal

On 02.03.2016 15:28, Paolo Abeni wrote: This patch add a rpm preuninstall scriptlet to cleanup the boot loader configuration on kernel package uninstall. The initrd for the to-be-removed kernel is deleted, too. Signed-off-by: Paolo Abeni --- scripts/package/mkspec | 5

Re: [PATCH] kbuild/mkspec: clean boot loader configuration on rpm removal

On 02.03.2016 15:28, Paolo Abeni wrote: This patch add a rpm preuninstall scriptlet to cleanup the boot loader configuration on kernel package uninstall. The initrd for the to-be-removed kernel is deleted, too. Signed-off-by: Paolo Abeni --- scripts/package/mkspec | 5 + 1 file changed,

Re: 4.4.1 skb_warn_bad_offload+0xc5/0x110

On 24.02.2016 02:46, Wakko Warner wrote: Please keep me in CC. Wakko Warner wrote: Hannes Frederic Sowa wrote: [full-quote for netdev] Hello, On 16.02.2016 01:08, Wakko Warner wrote: I've been seeing the following on some of my VMs ran under qemu. The VMs do not have internet

Re: 4.4.1 skb_warn_bad_offload+0xc5/0x110

On 24.02.2016 02:46, Wakko Warner wrote: Please keep me in CC. Wakko Warner wrote: Hannes Frederic Sowa wrote: [full-quote for netdev] Hello, On 16.02.2016 01:08, Wakko Warner wrote: I've been seeing the following on some of my VMs ran under qemu. The VMs do not have internet

Re: 4.4.1 skb_warn_bad_offload+0xc5/0x110

[full-quote for netdev] Hello, On 16.02.2016 01:08, Wakko Warner wrote: Please keep me in CC. I've been seeing the following on some of my VMs ran under qemu. The VMs do not have internet connectivity. This happened when some files were accessed via NFS to another VM (NOTE: Both VMs throw

Re: 4.4.1 skb_warn_bad_offload+0xc5/0x110

[full-quote for netdev] Hello, On 16.02.2016 01:08, Wakko Warner wrote: Please keep me in CC. I've been seeing the following on some of my VMs ran under qemu. The VMs do not have internet connectivity. This happened when some files were accessed via NFS to another VM (NOTE: Both VMs throw

Re: https://patchwork.ozlabs.org/patch/579654?

tes the loop as the size is zero without copying the credential information. Just wondering if this might have been lost in the noise ... I think the patch got lost, probably just resending is the easiest solution. ;) For the patch: Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: https://patchwork.ozlabs.org/patch/579654?

tes the loop as the size is zero without copying the credential information. Just wondering if this might have been lost in the noise ... I think the patch got lost, probably just resending is the easiest solution. ;) For the patch: Acked-by: Hannes Frederic Sowa Thanks, Hannes

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 03.02.2016 12:56, David Herrmann wrote: However, with Hannes' revised patch, a different DoS attack against dbus-daemon is possible. Imagine a peer that receives batches of FDs, but never dequeues them. They will be accounted on the inflight-limit of dbus-daemon, as such causing messages of

Re: [PATCH v3] net:Add sysctl_max_skb_frags

On 03.02.2016 13:20, Herbert Xu wrote: On Wed, Feb 03, 2016 at 12:36:21PM +0100, Hannes Frederic Sowa wrote: Agreed that it feels like a hack, but a rather simple one. I would consider this to be just a performance improvement. We certainly need a slow-path when virtio drivers submit gso

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 03.02.2016 12:36, Simon McVittie wrote: On 02/02/16 17:34, David Herrmann wrote: Furthermore, with this patch in place, a process better not pass any file-descriptors to an untrusted process. ... Did anyone notify the dbus maintainers of this? They might wanna document this, if not already

Re: [PATCH v3] net:Add sysctl_max_skb_frags

On 03.02.2016 12:25, Herbert Xu wrote: On Wed, Feb 03, 2016 at 09:26:57AM +0100, Hans Westgaard Ry wrote: Devices may have limits on the number of fragments in an skb they support. Current codebase uses a constant as maximum for number of fragments one skb can hold and use. When enabling

Re: [PATCH v3] net:Add sysctl_max_skb_frags

On 03.02.2016 12:25, Herbert Xu wrote: On Wed, Feb 03, 2016 at 09:26:57AM +0100, Hans Westgaard Ry wrote: Devices may have limits on the number of fragments in an skb they support. Current codebase uses a constant as maximum for number of fragments one skb can hold and use. When enabling

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 03.02.2016 12:36, Simon McVittie wrote: On 02/02/16 17:34, David Herrmann wrote: Furthermore, with this patch in place, a process better not pass any file-descriptors to an untrusted process. ... Did anyone notify the dbus maintainers of this? They might wanna document this, if not already

Re: [PATCH v3] net:Add sysctl_max_skb_frags

On 03.02.2016 13:20, Herbert Xu wrote: On Wed, Feb 03, 2016 at 12:36:21PM +0100, Hannes Frederic Sowa wrote: Agreed that it feels like a hack, but a rather simple one. I would consider this to be just a performance improvement. We certainly need a slow-path when virtio drivers submit gso

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 03.02.2016 12:56, David Herrmann wrote: However, with Hannes' revised patch, a different DoS attack against dbus-daemon is possible. Imagine a peer that receives batches of FDs, but never dequeues them. They will be accounted on the inflight-limit of dbus-daemon, as such causing messages of

Re: Bug 4.1.16: self-detected stall in net/unix/?

On 02.02.2016 17:25, Philipp Hahn wrote: Hi, we recently updated our kernel to 4.1.16 + patch for "unix: properly account for FDs passed over unix sockets" and have since then self-detected stalls triggered by the Samba daemon: > > > > [...] > > We have not yet been able to reproduce the

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 03.02.2016 01:57, Hannes Frederic Sowa wrote: On 02.02.2016 23:11, Linus Torvalds wrote: But I'm OK with that patch as is if you prefer it that way (maybe you want to use the cred to then test for root separately etc, out maybe there already was done use of cred as cred that I just missed

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 02.02.2016 23:11, Linus Torvalds wrote: [ sorry for the html mail, I'm out grocery shopping ] On Feb 2, 2016 13:55, "Hannes Frederic Sowa" wrote: I slightly tested the attached patch. Looks fine. I do wonder: if the only thing we use that "struct cred" for is to d

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

Hi Willy, On 02.02.2016 21:39, Willy Tarreau wrote: On Tue, Feb 02, 2016 at 09:32:56PM +0100, Hannes Frederic Sowa wrote: But "struct pid *" in unix_skb_parms should be enough to get us to corresponding "struct cred *" so we can decrement the correct counter during skb d

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 02.02.2016 21:44, Linus Torvalds wrote: On Tue, Feb 2, 2016 at 12:32 PM, Hannes Frederic Sowa wrote: Unfortunately we never transfer a scm_cookie via the skbs but merely use it to initialize unix_skb_parms structure in skb->cb and destroy it afterwards. Ok, I obviously didn't check v

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 02.02.2016 20:29, Linus Torvalds wrote: On Tue, Feb 2, 2016 at 10:29 AM, Hannes Frederic Sowa wrote: Anyway, can someone provide a high-level description of what exactly this patch is supposed to do? Which operation should be limited, who should inflight FDs be accounted on, and which

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

*files* in flight than their configured FD limit. See below for details.. Reported-by: socketp...@gmail.com Reported-by: Tetsuo Handa Mitigates: CVE-2013-4312 (Linux 2.0+) Suggested-by: Linus Torvalds Acked-by: Hannes Frederic Sowa Signed-off-by: Willy Tarreau --- v2: add reported-by, mitigates

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

; Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Signed-off-by: Willy Tarreau <w...@1wt.eu> --- v2: add reported-by, mitigates and acked-by. It would be nice if (if accepted) it would be backported to -stable as the issue is currently exploitable. --- include/linux/sched

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 02.02.2016 20:29, Linus Torvalds wrote: On Tue, Feb 2, 2016 at 10:29 AM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: Anyway, can someone provide a high-level description of what exactly this patch is supposed to do? Which operation should be limited, who should inflig

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 02.02.2016 21:44, Linus Torvalds wrote: On Tue, Feb 2, 2016 at 12:32 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: Unfortunately we never transfer a scm_cookie via the skbs but merely use it to initialize unix_skb_parms structure in skb->cb and destroy it afterwards

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

Hi Willy, On 02.02.2016 21:39, Willy Tarreau wrote: On Tue, Feb 02, 2016 at 09:32:56PM +0100, Hannes Frederic Sowa wrote: But "struct pid *" in unix_skb_parms should be enough to get us to corresponding "struct cred *" so we can decrement the correct counter during skb d

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 03.02.2016 01:57, Hannes Frederic Sowa wrote: On 02.02.2016 23:11, Linus Torvalds wrote: But I'm OK with that patch as is if you prefer it that way (maybe you want to use the cred to then test for root separately etc, out maybe there already was done use of cred as cred that I just missed

Re: [PATCH v2] unix: properly account for FDs passed over unix sockets

On 02.02.2016 23:11, Linus Torvalds wrote: [ sorry for the html mail, I'm out grocery shopping ] On Feb 2, 2016 13:55, "Hannes Frederic Sowa" <han...@stressinduktion.org> wrote: I slightly tested the attached patch. Looks fine. I do wonder: if the only thing we use t

Re: Bug 4.1.16: self-detected stall in net/unix/?

On 02.02.2016 17:25, Philipp Hahn wrote: Hi, we recently updated our kernel to 4.1.16 + patch for "unix: properly account for FDs passed over unix sockets" and have since then self-detected stalls triggered by the Samba daemon: > > > > [...] > > We have not yet been able to reproduce the

Re: [PATCH v2] net:Add sysctl_tcp_sg_max_skb_frags

On 27.01.2016 16:15, Eric Dumazet wrote: On Wed, 2016-01-27 at 14:20 +0100, Hans Westgaard Ry wrote: Devices may have limits on the number of fragments in an skb they support. Current codebase uses a constant as maximum for number of fragments one skb can hold and use. When enabling

Re: [PATCH v2] net:Add sysctl_tcp_sg_max_skb_frags

On 27.01.2016 16:15, Eric Dumazet wrote: On Wed, 2016-01-27 at 14:20 +0100, Hans Westgaard Ry wrote: Devices may have limits on the number of fragments in an skb they support. Current codebase uses a constant as maximum for number of fragments one skb can hold and use. When enabling

Re: [PATCH] af_unix: Fix splice-bind deadlock

Hello, On Sun, Jan 3, 2016, at 19:03, Rainer Weikusat wrote: > Rainer Weikusat writes: > > > Hannes Frederic Sowa writes: > >> On 27.12.2015 21:13, Rainer Weikusat wrote: > >>> -static int unix_mknod(const char *sun_path, umode_t mode, struct path > &g

Re: [PATCH] af_unix: Fix splice-bind deadlock

Hello, On Sun, Jan 3, 2016, at 19:03, Rainer Weikusat wrote: > Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: > > > Hannes Frederic Sowa <han...@stressinduktion.org> writes: > >> On 27.12.2015 21:13, Rainer Weikusat wrote: > >>>

Re: [PATCH] unix: properly account for FDs passed over unix sockets

On 29.12.2015 21:35, Willy Tarreau wrote: On Tue, Dec 29, 2015 at 03:48:45PM +0100, Hannes Frederic Sowa wrote: On 28.12.2015 15:14, Willy Tarreau wrote: It is possible for a process to allocate and accumulate far more FDs than the process' limit by sending them over a unix socket then closing

Re: [PATCH] unix: properly account for FDs passed over unix sockets

On 29.12.2015 21:35, Willy Tarreau wrote: On Tue, Dec 29, 2015 at 03:48:45PM +0100, Hannes Frederic Sowa wrote: On 28.12.2015 15:14, Willy Tarreau wrote: It is possible for a process to allocate and accumulate far more FDs than the process' limit by sending them over a unix socket then closing

Re: [PATCH] unix: properly account for FDs passed over unix sockets

On 28.12.2015 15:14, Willy Tarreau wrote: It is possible for a process to allocate and accumulate far more FDs than the process' limit by sending them over a unix socket then closing them to keep the process' fd count low. This change addresses this problem by keeping track of the number of FDs

Re: [PATCH] unix: properly account for FDs passed over unix sockets

On 28.12.2015 15:14, Willy Tarreau wrote: @@ -1528,10 +1546,8 @@ static int unix_attach_fds(struct scm_cookie *scm, struct sk_buff *skb) if (!UNIXCB(skb).fp) return -ENOMEM; - if (unix_sock_count) { - for (i = scm->fp->count - 1; i >= 0; i--) -

Re: [PATCH] netconsole: Initialize after all core networking drivers

On 29.12.2015 00:21, Cong Wang wrote: On Thu, Dec 24, 2015 at 2:25 AM, Hannes Frederic Sowa wrote: Hi, On 24.12.2015 00:03, Calvin Owens wrote: This patch addresses the issue cited in 7332a13b038be05c by making vxlan actually check if ipv6 is loaded, and reverts it to module_init() so

Re: [PATCH] af_unix: Fix splice-bind deadlock

Hello Rainer, On 27.12.2015 21:13, Rainer Weikusat wrote: -static int unix_mknod(const char *sun_path, umode_t mode, struct path *res) +static int unix_mknod(struct dentry *dentry, struct path *path, umode_t mode, + struct path *res) { - struct dentry *dentry; -

Re: [PATCH] af_unix: Fix splice-bind deadlock

Hello Rainer, On 27.12.2015 21:13, Rainer Weikusat wrote: -static int unix_mknod(const char *sun_path, umode_t mode, struct path *res) +static int unix_mknod(struct dentry *dentry, struct path *path, umode_t mode, + struct path *res) { - struct dentry *dentry; -

Re: [PATCH] netconsole: Initialize after all core networking drivers

On 29.12.2015 00:21, Cong Wang wrote: On Thu, Dec 24, 2015 at 2:25 AM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: Hi, On 24.12.2015 00:03, Calvin Owens wrote: This patch addresses the issue cited in 7332a13b038be05c by making vxlan actually check if ipv6 is loaded, and r

Re: [PATCH] unix: properly account for FDs passed over unix sockets

On 28.12.2015 15:14, Willy Tarreau wrote: It is possible for a process to allocate and accumulate far more FDs than the process' limit by sending them over a unix socket then closing them to keep the process' fd count low. This change addresses this problem by keeping track of the number of FDs

Re: [PATCH] unix: properly account for FDs passed over unix sockets

On 28.12.2015 15:14, Willy Tarreau wrote: @@ -1528,10 +1546,8 @@ static int unix_attach_fds(struct scm_cookie *scm, struct sk_buff *skb) if (!UNIXCB(skb).fp) return -ENOMEM; - if (unix_sock_count) { - for (i = scm->fp->count - 1; i >= 0; i--) -

Re: [PATCH] netconsole: Initialize after all core networking drivers

Hi, On 24.12.2015 00:03, Calvin Owens wrote: > On Thursday 12/17 at 17:46 -0800, Calvin Owens wrote: >> On Thursday 12/17 at 17:08 -0800, Eric Dumazet wrote: >>> On Thu, 2015-12-17 at 15:52 -0800, Calvin Owens wrote: With built-in netconsole and IXGBE, configuring netconsole via the kernel

Re: [PATCH] netconsole: Initialize after all core networking drivers

Hi, On 24.12.2015 00:03, Calvin Owens wrote: > On Thursday 12/17 at 17:46 -0800, Calvin Owens wrote: >> On Thursday 12/17 at 17:08 -0800, Eric Dumazet wrote: >>> On Thu, 2015-12-17 at 15:52 -0800, Calvin Owens wrote: With built-in netconsole and IXGBE, configuring netconsole via the kernel

Re: net, ipv6: out of bounds access in secret_stable

t; > Looks like we don't initialize the array on stack for write case. > At least other callers always initialize the data for both read > and write. > > Please try the attached patch. Your patch is right. I am surprised you need to initialize the buffer passed down to proc_dostring so tha

Re: net, ipv6: out of bounds access in secret_stable

/ipv6/addrconf.c:5395) > > Looks like we don't initialize the array on stack for write case. > At least other callers always initialize the data for both read > and write. > > Please try the attached patch. Your patch is right. I am surprised you need to initialize the buffer passed

Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

On 17.12.2015 16:28, Rainer Weikusat wrote: > Hannes Frederic Sowa writes: >> On 16.12.2015 21:09, Rainer Weikusat wrote: >>> With b3ca9b02b00704053a38bfe4c31dbbb9c13595d0, the AF_UNIX SOCK_STREAM >>> receive code was changed from using mutex_lock(>readlock) t

Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

On 16.12.2015 21:09, Rainer Weikusat wrote: > With b3ca9b02b00704053a38bfe4c31dbbb9c13595d0, the AF_UNIX SOCK_STREAM > receive code was changed from using mutex_lock(>readlock) to > mutex_lock_interruptible(>readlock) to prevent signals from being > delayed for an indefinite time if a thread

Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

On 16.12.2015 21:09, Rainer Weikusat wrote: > With b3ca9b02b00704053a38bfe4c31dbbb9c13595d0, the AF_UNIX SOCK_STREAM > receive code was changed from using mutex_lock(>readlock) to > mutex_lock_interruptible(>readlock) to prevent signals from being > delayed for an indefinite time if a thread

Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

On 17.12.2015 16:28, Rainer Weikusat wrote: > Hannes Frederic Sowa <han...@stressinduktion.org> writes: >> On 16.12.2015 21:09, Rainer Weikusat wrote: >>> With b3ca9b02b00704053a38bfe4c31dbbb9c13595d0, the AF_UNIX SOCK_STREAM >>> receive code was change

Re: Information leak in pptp_bind

On 14.12.2015 11:38, Dmitry Vyukov wrote: > The following program leak various uninit garbage including kernel > addresses and whatever is on kernel stack, in particular defeating > ASLR. The issue is in pptp_bind which does not verify sockaddr_len. Thanks for the report! I send out a patch

Re: Information leak in pptp_bind

On 14.12.2015 11:38, Dmitry Vyukov wrote: > The following program leak various uninit garbage including kernel > addresses and whatever is on kernel stack, in particular defeating > ASLR. The issue is in pptp_bind which does not verify sockaddr_len. Thanks for the report! I send out a patch

Re: bpf: undefined shift in __bpf_prog_run

Hello, On Fri, Dec 4, 2015, at 20:48, Dmitry Vyukov wrote: > On Fri, Dec 4, 2015 at 8:26 PM, David Miller wrote: > > From: Alexei Starovoitov > > Date: Fri, 4 Dec 2015 11:10:15 -0800 > > > >> just don't generate random bpf programs with such shifts. > > > > Agreed, it is exactly the same as if

Re: time: signed integer overflow in ktime_add_safe

Hello, On Fri, Dec 4, 2015, at 12:05, Dmitry Vyukov wrote: > UBSAN reports undefined behavior in ktime_add_safe: > > UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16 > signed integer overflow: > 9223372036854775807 + 1 cannot be represented in type 'long long > int' > CPU: 3

Re: time: signed integer overflow in ktime_add_safe

Hello, On Fri, Dec 4, 2015, at 12:05, Dmitry Vyukov wrote: > UBSAN reports undefined behavior in ktime_add_safe: > > UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16 > signed integer overflow: > 9223372036854775807 + 1 cannot be represented in type 'long long > int' > CPU: 3

Re: bpf: undefined shift in __bpf_prog_run

Hello, On Fri, Dec 4, 2015, at 20:48, Dmitry Vyukov wrote: > On Fri, Dec 4, 2015 at 8:26 PM, David Miller wrote: > > From: Alexei Starovoitov > > Date: Fri, 4 Dec 2015 11:10:15 -0800 > > > >> just don't generate random bpf programs with such

Re: Asterisk deadlocks since Kernel 4.1

Hello, On Wed, Dec 2, 2015, at 18:15, Philipp Hahn wrote: > Hi, > > Am 02.12.2015 um 10:45 schrieb Stefan Priebe - Profihost AG: > > here are the results. > > > > It works with 4.1. > > It works with 4.2. > > It does not work with 4.1.13. > > the patches were first commitet in v4.3-rc3 and

Re: Asterisk deadlocks since Kernel 4.1

Hello Stefan, Stefan Priebe - Profihost AG writes: > here are the results. > > It works with 4.1. > It works with 4.2. > It does not work with 4.1.13. > > git bisect tells me it stopped working after those two commits were applied: > > commit d48623677191e0f035d7afd344f92cf880b01f8e > Author:

Re: Asterisk deadlocks since Kernel 4.1

Hello, On Wed, Dec 2, 2015, at 18:15, Philipp Hahn wrote: > Hi, > > Am 02.12.2015 um 10:45 schrieb Stefan Priebe - Profihost AG: > > here are the results. > > > > It works with 4.1. > > It works with 4.2. > > It does not work with 4.1.13. > > the patches were first commitet in v4.3-rc3 and

Re: Asterisk deadlocks since Kernel 4.1

Hello Stefan, Stefan Priebe - Profihost AG writes: > here are the results. > > It works with 4.1. > It works with 4.2. > It does not work with 4.1.13. > > git bisect tells me it stopped working after those two commits were applied: > > commit

Re: net: Use after free in dst_release on boot

Hi, On Fri, Nov 27, 2015, at 21:48, Sasha Levin wrote: > [ 117.057618] BUG: KASAN: use-after-free in dst_release+0x9a/0xc0 at > addr 8806cf7c7560 > > [ 117.058566] Read of size 2 by task swapper/0/1 > Can you check if the following commit was already applied? net wasn't merged into

Re: [PATCH net] bridge: Only call /sbin/bridge-stp for the initial network namespace

On Mon, Nov 30, 2015, at 22:38, Eric W. Biederman wrote: > Signed-off-by: "Eric W. Biederman" > --- > net/bridge/br_stp_if.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c > index 5396ff08af32..742fa89528ab 100644 >

Re: [PATCH net] ipv6: add complete rcu protection around np->opt

On Tue, Dec 1, 2015, at 14:05, Eric Dumazet wrote: > On Tue, 2015-12-01 at 12:11 +0100, Hannes Frederic Sowa wrote: > > Hi Eric, > > > > On Mon, Nov 30, 2015, at 04:37, Eric Dumazet wrote: > > > - opt = xchg(>opt, NULL); >

Re: [PATCH net] ipv6: add complete rcu protection around np->opt

Hi Eric, On Mon, Nov 30, 2015, at 04:37, Eric Dumazet wrote: > - opt = xchg(>opt, NULL); > - if (opt) > - sock_kfree_s(sk, opt, opt->tot_len); > + opt = xchg((__force struct ipv6_txoptions > **)>opt, >

Re: [PATCH net] ipv6: add complete rcu protection around np->opt

On Tue, Dec 1, 2015, at 14:05, Eric Dumazet wrote: > On Tue, 2015-12-01 at 12:11 +0100, Hannes Frederic Sowa wrote: > > Hi Eric, > > > > On Mon, Nov 30, 2015, at 04:37, Eric Dumazet wrote: > > > - opt = xchg(>opt, NULL); >

Re: [PATCH net] ipv6: add complete rcu protection around np->opt

Hi Eric, On Mon, Nov 30, 2015, at 04:37, Eric Dumazet wrote: > - opt = xchg(>opt, NULL); > - if (opt) > - sock_kfree_s(sk, opt, opt->tot_len); > + opt = xchg((__force struct ipv6_txoptions > **)>opt, >

Re: net: Use after free in dst_release on boot

Hi, On Fri, Nov 27, 2015, at 21:48, Sasha Levin wrote: > [ 117.057618] BUG: KASAN: use-after-free in dst_release+0x9a/0xc0 at > addr 8806cf7c7560 > > [ 117.058566] Read of size 2 by task swapper/0/1 > Can you check if the following commit was already applied? net wasn't merged into

Re: [PATCH net] bridge: Only call /sbin/bridge-stp for the initial network namespace

On Mon, Nov 30, 2015, at 22:38, Eric W. Biederman wrote: > Signed-off-by: "Eric W. Biederman" > --- > net/bridge/br_stp_if.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c > index

Re: use-after-free in sock_wake_async

On Thu, Nov 26, 2015, at 18:09, Eric Dumazet wrote: > On Thu, 2015-11-26 at 18:03 +0100, Hannes Frederic Sowa wrote: > > > My rationale was like this: we already have rcu to free the wq, so we > > don't add any more callbacks as current code. sock_alloc is right now > > 1

Re: use-after-free in sock_wake_async

On Thu, Nov 26, 2015, at 16:51, Eric Dumazet wrote: > On Thu, 2015-11-26 at 14:32 +0100, Hannes Frederic Sowa wrote: > > Hannes Frederic Sowa writes: > > > > > > > I have seen filesystems already doing so in .destroy_inode, that's why I > > > am asking. Th

Re: use-after-free in sock_wake_async

On Thu, Nov 26, 2015, at 14:32, Hannes Frederic Sowa wrote: > diff --git a/include/net/sock.h b/include/net/sock.h > index 7f89e4b..ae34da1 100644 > --- a/include/net/sock.h > +++ b/include/net/sock.h > @@ -1674,7 +1674,7 @@ static inline void sock_orphan(struct sock *sk) >

Re: use-after-free in sock_wake_async

Hannes Frederic Sowa writes: > I have seen filesystems already doing so in .destroy_inode, that's why I > am asking. The allocation happens the same way as we do with sock_alloc, > e.g. shmem. I actually thought that struct inode already provides an > rcu_head for exactly that

Re: use-after-free in sock_wake_async

Hannes Frederic Sowa <han...@stressinduktion.org> writes: > I have seen filesystems already doing so in .destroy_inode, that's why I > am asking. The allocation happens the same way as we do with sock_alloc, > e.g. shmem. I actually thought that struct inode already provide

Re: use-after-free in sock_wake_async

On Thu, Nov 26, 2015, at 14:32, Hannes Frederic Sowa wrote: > diff --git a/include/net/sock.h b/include/net/sock.h > index 7f89e4b..ae34da1 100644 > --- a/include/net/sock.h > +++ b/include/net/sock.h > @@ -1674,7 +1674,7 @@ static inline void sock_orphan(struct sock *sk) >

Re: use-after-free in sock_wake_async

On Thu, Nov 26, 2015, at 16:51, Eric Dumazet wrote: > On Thu, 2015-11-26 at 14:32 +0100, Hannes Frederic Sowa wrote: > > Hannes Frederic Sowa <han...@stressinduktion.org> writes: > > > > > > > I have seen filesystems already doing so in .destroy

Re: use-after-free in sock_wake_async

On Thu, Nov 26, 2015, at 18:09, Eric Dumazet wrote: > On Thu, 2015-11-26 at 18:03 +0100, Hannes Frederic Sowa wrote: > > > My rationale was like this: we already have rcu to free the wq, so we > > don't add any more callbacks as current code. sock_alloc is right now > > 1

Re: use-after-free in sock_wake_async

On Wed, Nov 25, 2015, at 23:43, Eric Dumazet wrote: > On Wed, 2015-11-25 at 23:32 +0100, Hannes Frederic Sowa wrote: > > On Wed, Nov 25, 2015, at 23:09, Eric Dumazet wrote: > > > On Wed, 2015-11-25 at 20:57 +, Rainer Weikusat wrote: > > > > > > > I do

Re: use-after-free in sock_wake_async

On Wed, Nov 25, 2015, at 23:09, Eric Dumazet wrote: > On Wed, 2015-11-25 at 20:57 +, Rainer Weikusat wrote: > > > I do agree that keeping the ->sk_data_ready outside of the lock will > > very likely have performance advantages. That's just something I > > wouldn't have undertaken because I'd

Re: use-after-free in sock_wake_async

On Wed, Nov 25, 2015, at 23:09, Eric Dumazet wrote: > On Wed, 2015-11-25 at 20:57 +, Rainer Weikusat wrote: > > > I do agree that keeping the ->sk_data_ready outside of the lock will > > very likely have performance advantages. That's just something I > > wouldn't have undertaken because I'd

Re: use-after-free in sock_wake_async

On Wed, Nov 25, 2015, at 23:43, Eric Dumazet wrote: > On Wed, 2015-11-25 at 23:32 +0100, Hannes Frederic Sowa wrote: > > On Wed, Nov 25, 2015, at 23:09, Eric Dumazet wrote: > > > On Wed, 2015-11-25 at 20:57 +, Rainer Weikusat wrote: > > > > > > > I do

Re: [PATCH net] ipv6: distinguish frag queues by device for multicast and link-local packets

ble, thanks! I reviewed it earlier and agree last time that this patch is necessary. Unfortunately forgot to ack before. :( Acked-by: Hannes Frederic Sowa In IPv4 as in IPv6 global addresses we have to expect packets coming over multiple interfaces, it is only correct for local and multicast scop

Re: [RFC PATCH 2/2] Crypto kernel tls socket

Hello, Stephan Mueller writes: > Am Dienstag, 24. November 2015, 18:34:55 schrieb Herbert Xu: > > Hi Herbert, > >>On Mon, Nov 23, 2015 at 09:43:02AM -0800, Dave Watson wrote: >>> Userspace crypto interface for TLS. Currently supports gcm(aes) 128bit >>> only, however the interface is the same

Re: [PATCH net] ipv6: distinguish frag queues by device for multicast and link-local packets

ments. > > Applied and queued up for -stable, thanks! I reviewed it earlier and agree last time that this patch is necessary. Unfortunately forgot to ack before. :( Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> In IPv4 as in IPv6 global addresses we have to expect

Re: [RFC PATCH 2/2] Crypto kernel tls socket

Hello, Stephan Mueller writes: > Am Dienstag, 24. November 2015, 18:34:55 schrieb Herbert Xu: > > Hi Herbert, > >>On Mon, Nov 23, 2015 at 09:43:02AM -0800, Dave Watson wrote: >>> Userspace crypto interface for TLS. Currently supports gcm(aes) 128bit >>> only, however the

Re: [RFC PATCH 0/2] Crypto kernel TLS socket

Hello, On Mon, Nov 23, 2015, at 18:42, Dave Watson wrote: > An approach for a kernel TLS socket. > > Only the symmetric encryption / decryption is done in-kernel, as well > as minimal framing handling. The handshake is kept in userspace, and > the negotiated cipher / keys / IVs are then set on

Re: Asterisk deadlocks since Kernel 4.1

On Mon, Nov 23, 2015, at 13:44, Stefan Priebe - Profihost AG wrote: > Am 19.11.2015 um 20:51 schrieb Stefan Priebe: > > > > Am 19.11.2015 um 14:19 schrieb Florian Weimer: > >> On 11/19/2015 01:46 PM, Stefan Priebe - Profihost AG wrote: > >> > >>> I can try Kernel 4.4-rc1 next week. Or something

Re: Deadlock between bind and splice

On Mon, Nov 23, 2015, at 09:32, Dmitry Vyukov wrote: > On Tue, Nov 10, 2015 at 3:59 AM, Al Viro wrote: > > On Tue, Nov 10, 2015 at 02:38:54AM +, Al Viro wrote: > >> On Fri, Nov 06, 2015 at 07:42:15AM -0800, Eric Dumazet wrote: > >> > >> > Thank you for this report. > >> > > >> > pipe is part

Re: [RFC PATCH 0/2] Crypto kernel TLS socket

Hello, On Mon, Nov 23, 2015, at 18:42, Dave Watson wrote: > An approach for a kernel TLS socket. > > Only the symmetric encryption / decryption is done in-kernel, as well > as minimal framing handling. The handshake is kept in userspace, and > the negotiated cipher / keys / IVs are then set on

Re: Asterisk deadlocks since Kernel 4.1

On Mon, Nov 23, 2015, at 13:44, Stefan Priebe - Profihost AG wrote: > Am 19.11.2015 um 20:51 schrieb Stefan Priebe: > > > > Am 19.11.2015 um 14:19 schrieb Florian Weimer: > >> On 11/19/2015 01:46 PM, Stefan Priebe - Profihost AG wrote: > >> > >>> I can try Kernel 4.4-rc1 next week. Or something

Re: Deadlock between bind and splice

On Mon, Nov 23, 2015, at 09:32, Dmitry Vyukov wrote: > On Tue, Nov 10, 2015 at 3:59 AM, Al Viro wrote: > > On Tue, Nov 10, 2015 at 02:38:54AM +, Al Viro wrote: > >> On Fri, Nov 06, 2015 at 07:42:15AM -0800, Eric Dumazet wrote: > >> > >> > Thank you for this report. >

Re: Asterisk deadlocks since Kernel 4.1

On Thu, Nov 19, 2015, at 12:43, Stefan Priebe - Profihost AG wrote: > > Am 19.11.2015 um 12:41 schrieb Hannes Frederic Sowa: > > On Thu, Nov 19, 2015, at 10:56, Stefan Priebe - Profihost AG wrote: > >> OK it had a livelock again. It just took more time. > >

Re: Asterisk deadlocks since Kernel 4.1

On Thu, Nov 19, 2015, at 10:56, Stefan Priebe - Profihost AG wrote: > OK it had a livelock again. It just took more time. > > So here is the data: Thanks, I couldn't reproduce it so far with simple threaded resolver loop on your kernel. :/ Your data is useless if you don't also provide the file

Re: Asterisk deadlocks since Kernel 4.1

On Thu, Nov 19, 2015, at 12:43, Stefan Priebe - Profihost AG wrote: > > Am 19.11.2015 um 12:41 schrieb Hannes Frederic Sowa: > > On Thu, Nov 19, 2015, at 10:56, Stefan Priebe - Profihost AG wrote: > >> OK it had a livelock again. It just took more time. > >

Re: Asterisk deadlocks since Kernel 4.1

On Thu, Nov 19, 2015, at 10:56, Stefan Priebe - Profihost AG wrote: > OK it had a livelock again. It just took more time. > > So here is the data: Thanks, I couldn't reproduce it so far with simple threaded resolver loop on your kernel. :/ Your data is useless if you don't also provide the file

Re: Asterisk deadlocks since Kernel 4.1

On Wed, Nov 18, 2015, at 22:42, Stefan Priebe wrote: > > Am 18.11.2015 um 22:40 schrieb Hannes Frederic Sowa: > > On Wed, Nov 18, 2015, at 22:36, Stefan Priebe wrote: > >> sorry here it is. What I'm wondering is why is there ipv6 stuff? I don't > >> have ipv

Re: Asterisk deadlocks since Kernel 4.1

On Wed, Nov 18, 2015, at 22:36, Stefan Priebe wrote: > sorry here it is. What I'm wondering is why is there ipv6 stuff? I don't > have ipv6 except for link local. Could it be this one? > > https://bugzilla.redhat.com/show_bug.cgi?id=505105#c79 > > Thread 31 (Thread 0x7f295c011700 (LWP 26654)):

Re: Asterisk deadlocks since Kernel 4.1

On Wed, Nov 18, 2015, at 22:20, Stefan Priebe wrote: > you mean just: > la /proc/$pid/fd ls -l /proc/pid/fd/ the numbers in brackets in return from readlink are the inode numbers. > and > > cat /proc/net/netlink Exactly, last row is the inode number. Bye, Hannes -- To unsubscribe from this

Re: Asterisk deadlocks since Kernel 4.1

On Wed, Nov 18, 2015, at 21:23, Stefan Priebe wrote: > > Am 17.11.2015 um 20:43 schrieb Thomas Gleixner: > > On Tue, 17 Nov 2015, Stefan Priebe wrote: > >> I've now also two gdb backtraces from two crashes: > >> http://pastebin.com/raw.php?i=yih5jNt8 > >> > >>

<    1   2   3   4   5   6   7   8   9   10   >