Re: [PATCH] l2tp: Restore socket refcount when sendmsg succeeds

On Fri, Mar 01, 2013 at 02:12:52PM -0500, David Miller wrote: From: Guillaume Nault g.na...@alphalink.fr Date: Fri, 1 Mar 2013 16:02:02 +0100 The sendmsg() syscall handler for PPPoL2TP doesn't decrease the socket reference counter after successful transmissions. Any successful sendmsg

[PATCH] l2tp: Restore socket refcount when sendmsg succeeds

: sta...@vger.kernel.org Signed-off-by: Guillaume Nault g.na...@alphalink.fr --- net/l2tp/l2tp_ppp.c |1 + 1 file changed, 1 insertion(+) diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c index 3f4e3af..6a53371 100644 --- a/net/l2tp/l2tp_ppp.c +++ b/net/l2tp/l2tp_ppp.c @@ -355,6 +355,7

Re: [PATCH 3.2 000/102] 3.2.64-rc1 review

On Sat, Nov 01, 2014 at 10:28:02PM +, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.2.64 release. There are 102 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. You

Re: [Linux 4.2-rc8+...v4.3-rc2] REGRESSION: ppp: circular locking dependency detected: [pppd] ppp_dev_uninit() | rtnl_lock()

On Wed, Sep 23, 2015 at 08:06:16AM +0200, Sedat Dilek wrote: > Without reverting the below culprit ppp patch... > > commit/?id=8cb775bc0a34dc596837e7da03fd22c747be618b > ("ppp: fix device unregistration upon netns deletion") > > ...I have an unstable Internet connection via

Re: [Linux 4.2-rc8+...v4.3-rc2] REGRESSION: ppp: circular locking dependency detected: [pppd] ppp_dev_uninit() | rtnl_lock()

On Wed, Sep 23, 2015 at 11:21:50PM +0200, Sedat Dilek wrote: > On Wed, Sep 23, 2015 at 10:46 PM, Sedat Dilek <sedat.di...@gmail.com> wrote: > > On Wed, Sep 23, 2015 at 12:38 PM, Guillaume Nault <g.na...@alphalink.fr> > > wrote: > > Do you mind to send a proper p

Re: net/ppp: use-after-free in ppp_unregister_channel

On Wed, Mar 16, 2016 at 11:14:42PM +0800, Baozeng Ding wrote: > Dear all, > I've got the following use-after-free report while running syzkaller > fuzzer. Unfortunately no reproducer. It was found in the Linux kernel > version(4.4, on commit 9638685e32af961943b679fcb72d4ddd458eb18f). > >

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote: > static int ppp_open(struct inode *inode, struct file *file) > { > /* >* This could (should?) be enforced by the permissions on /dev/ppp. >*/ > if (!capable(CAP_NET_ADMIN)) > return -EPERM; >

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote: > On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote: > > On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.na...@alphalink.fr> > > wrote: > > > On Sun, May 01, 2016 at 09:38:57PM +0800, Wan

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 03, 2016 at 12:35:12PM +0200, Richard Weinberger wrote: > On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault <g.na...@alphalink.fr> wrote: > > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote: > >> static int ppp_open(struct inode *

Re: net/l2tp: use-after-free write in l2tp_ip6_close

On Mon, Nov 07, 2016 at 11:35:26PM +0100, Andrey Konovalov wrote: > Hi, > > I've got the following error report while running the syzkaller fuzzer: > > == > BUG: KASAN: use-after-free in l2tp_ip6_close+0x239/0x2a0 at addr >

Re: probably serious conntrack/netfilter panic, 4.8.14, timers and intel turbo

Cc: netfilter-de...@vger.kernel.org, I'm afraid I'll need some help for this case. On Sat, Dec 17, 2016 at 09:48:13PM +0200, Denys Fedoryshchenko wrote: > Hi, > > I posted recently several netfilter related crashes, didn't got any answers, > one of them started to happen quite often on loaded

Re: [PATCH 4.4 00/60] 4.4.40-stable review

On Wed, Jan 04, 2017 at 09:46:45PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.40 release. > There are 60 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

Re: [PATCH net-next v5 2/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

On Tue, Apr 11, 2017 at 09:39:58AM -0700, R Parameswaran wrote: > Hi Guillaume, > > On Tue, Apr 11, 2017 at 3:40 AM, Guillaume Nault <g.na...@alphalink.fr> wrote: > > On Wed, Apr 05, 2017 at 05:00:07PM -0700, R. Parameswaran wrote: > >> > >> Chang

Re: [PATCH net-next v1 1/1] L2TP device MTU setup - tunnel socket needs a lock

tures to derive the > socket's IP overhead. Thanks. Tested-by: Guillaume Nault <g.na...@alphalink.fr> BTW, you don't need to add "v1" for the first version of a patch. There's also no need for numbering pathes when there's only one in the series. And we normally prefix the commit messa

Re: [PATCH net-next v5 2/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

On Wed, Apr 05, 2017 at 05:00:07PM -0700, R. Parameswaran wrote: > > Change-set here uses the new kernel function, kernel_sock_ip_overhead(), > to factor the outer IP overhead on the L2TP tunnel socket (including > IP Options, if any) when calculating the default MTU for an Ethernet > pseudowire,

Re: [PATCH] net: l2tp: mark expected switch fall-through

nla_put_u16(skb, L2TP_ATTR_UDP_DPORT, > ntohs(inet->inet_dport))) > goto nla_put_failure; > - /* NOBREAK */ > + /* fall through */ > case L2TP_ENCAPTYPE_IP: > Nit: extra whitespace before '*/' (just couldn't restrai

Re: [PATCH 1/1] l2tp: cleanup l2tp_tunnel_delete calls

rn value > warnings. > > Kill these now useless casts. > Acked-by: Guillaume Nault <g.na...@alphalink.fr>

Re: KASAN: out-of-bounds Read in ip6_xmit

On Tue, May 08, 2018 at 09:45:25PM -0700, Eric Biggers wrote: > On Sun, Jan 28, 2018 at 11:24:01AM -0800, syzbot wrote: > > Hello, > > > > syzbot hit the following crash on net-next commit > > 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +) > > Merge branch

Re: KASAN: use-after-free Read in remove_wait_queue (2)

On Tue, May 22, 2018 at 08:29:58PM -0700, Eric Biggers wrote: > On Fri, May 18, 2018 at 06:02:23PM +0200, Guillaume Nault wrote: > > On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote: > > > [+ppp list and maintainer] > > > > > > This is a bug in ppp_

Re: [PATCH v2] ppp: remove the PPPIOCDETACH ioctl

table submissions himself. Using a 'PATCH net' subject prefix would have made it clear that this patch was fixing some released code and should be considered for -stable backport. Reviewed-by: Guillaume Nault <g.na...@alphalink.fr> Tested-by: Guillaume Nault <g.na...@alphalink.fr>

Re: KASAN: use-after-free Read in remove_wait_queue (2)

On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote: > [+ppp list and maintainer] > > This is a bug in ppp_generic.c; it still happens on Linus' tree and it's > easily > reproducible, see program below. The bug is that the PPPIOCDETACH ioctl > doesn't > consider that the file can

Re: [PATCH] ppp: remove the PPPIOCDETACH ioctl

On Tue, May 22, 2018 at 08:59:52PM -0700, Eric Biggers wrote: > From: Eric Biggers > > The PPPIOCDETACH ioctl effectively tries to "close" the given ppp file > before f_count has reached 0, which is fundamentally a bad idea. It > does check 'f_count < 2', which excludes

Re: possible deadlock in ppp_dev_uninit

On Wed, Jan 03, 2018 at 10:58:01PM -0800, syzbot wrote: > Hello, > > > WARNING: possible recursive locking detected > 4.15.0-rc6-next-20180103+ #87 Not tainted > > syzkaller221540/3462 is trying to acquire

Re: possible deadlock in ppp_dev_uninit

On Fri, Jan 05, 2018 at 07:15:31PM +0100, Guillaume Nault wrote: > That's probably worth a test anyway. > Copy/paste error :-/ Here's a version that should apply cleanly. #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master 8< diff --git a/dr

Re: kernel BUG at net/core/skbuff.c:LINE! (2)

On Tue, Jan 16, 2018 at 04:21:40PM +0800, Xin Long wrote: > ipv4 tunnels don't really set dev->hard_header_len properly, > we may should fix it in pppoe by using needed_headroom, > as what it doesn't in arp_create. > I'm a bit in doubt about which device needs to be fixed. Should ip_gre set

Re: KMSAN: uninit-value in strnlen

On Mon, Apr 23, 2018 at 01:23:01AM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on https://github.com/google/kmsan.git/master > commit > a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +) > kmsan: disable assembly checksums > syzbot dashboard link: >

Re: [PATCH] l2tp: fix l2tp_eth_dev_xmit()'s return type

On Tue, Apr 24, 2018 at 03:18:53PM +0200, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too.

Re: syzbot rcu/debugobjects warning

On Sat, Mar 24, 2018 at 11:29:42PM -0700, Joel Fernandes wrote: > On Fri, Mar 23, 2018 at 1:41 PM, Thomas Gleixner wrote: > > On Fri, 23 Mar 2018, Joel Fernandes wrote: > >> On Fri, Mar 23, 2018 at 2:11 AM, Thomas Gleixner > >> wrote: > >> > On Thu, 22

Re: [PATCH 4.4 063/114] l2tp: hold socket before dropping lock in l2tp_ip{, 6}_recv()

> > [ Upstream commit a3c18422a4b4e108bcf6a2328f48867e1003fd95 ] > > Socket must be held while under the protection of the l2tp lock; there > is no guarantee that sk remains valid after the read_unlock_bh() call. > > Same issue for l2tp_ip and l2tp_ip6. > > Signed-off-by: Guillau

Re: [PATCH 4.4 063/114] l2tp: hold socket before dropping lock in l2tp_ip{, 6}_recv()

On Fri, Nov 09, 2018 at 08:28:56AM -0800, Greg Kroah-Hartman wrote: > On Fri, Nov 09, 2018 at 04:33:32PM +0100, Guillaume Nault wrote: > > On Thu, Nov 08, 2018 at 01:51:18PM -0800, Greg Kroah-Hartman wrote: > > > 4.4-stable review patch. If anyone has any objections, please

[PATCH] l2tp: Restore socket refcount when sendmsg succeeds

: Signed-off-by: Guillaume Nault --- net/l2tp/l2tp_ppp.c |1 + 1 file changed, 1 insertion(+) diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c index 3f4e3af..6a53371 100644 --- a/net/l2tp/l2tp_ppp.c +++ b/net/l2tp/l2tp_ppp.c @@ -355,6 +355,7 @@ static int pppol2tp_sendmsg(struct kiocb

Re: [PATCH] l2tp: Restore socket refcount when sendmsg succeeds

On Fri, Mar 01, 2013 at 02:12:52PM -0500, David Miller wrote: > From: Guillaume Nault > Date: Fri, 1 Mar 2013 16:02:02 +0100 > > > The sendmsg() syscall handler for PPPoL2TP doesn't decrease the socket > > reference counter after successful transmissions. Any successful &g

Re: syzbot rcu/debugobjects warning

On Sat, Mar 24, 2018 at 11:29:42PM -0700, Joel Fernandes wrote: > On Fri, Mar 23, 2018 at 1:41 PM, Thomas Gleixner wrote: > > On Fri, 23 Mar 2018, Joel Fernandes wrote: > >> On Fri, Mar 23, 2018 at 2:11 AM, Thomas Gleixner > >> wrote: > >> > On Thu, 22 Mar 2018, Joel Fernandes wrote: > >>

Re: KASAN: out-of-bounds Read in ip6_xmit

On Tue, May 08, 2018 at 09:45:25PM -0700, Eric Biggers wrote: > On Sun, Jan 28, 2018 at 11:24:01AM -0800, syzbot wrote: > > Hello, > > > > syzbot hit the following crash on net-next commit > > 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +) > > Merge branch

Re: KASAN: use-after-free Read in remove_wait_queue (2)

On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote: > [+ppp list and maintainer] > > This is a bug in ppp_generic.c; it still happens on Linus' tree and it's > easily > reproducible, see program below. The bug is that the PPPIOCDETACH ioctl > doesn't > consider that the file can

Re: possible deadlock in ppp_dev_uninit

On Wed, Jan 03, 2018 at 10:58:01PM -0800, syzbot wrote: > Hello, > > > WARNING: possible recursive locking detected > 4.15.0-rc6-next-20180103+ #87 Not tainted > > syzkaller221540/3462 is trying to acquire

Re: possible deadlock in ppp_dev_uninit

On Fri, Jan 05, 2018 at 07:15:31PM +0100, Guillaume Nault wrote: > That's probably worth a test anyway. > Copy/paste error :-/ Here's a version that should apply cleanly. #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master 8< diff --git a/dr

Re: KMSAN: uninit-value in strnlen

On Mon, Apr 23, 2018 at 01:23:01AM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on https://github.com/google/kmsan.git/master > commit > a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +) > kmsan: disable assembly checksums > syzbot dashboard link: >

Re: [PATCH] l2tp: fix l2tp_eth_dev_xmit()'s return type

On Tue, Apr 24, 2018 at 03:18:53PM +0200, Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too.

Re: Urgent: BUG: PPP ioctl Transport endpoint is not connected

On Wed, Dec 09, 2020 at 04:47:52PM +0200, Martin Zaharinov wrote: > Hi All > > I have problem with latest kernel release > And the problem is base on this late problem : > > >

Re: Urgent: BUG: PPP ioctl Transport endpoint is not connected

On Wed, Dec 09, 2020 at 06:57:44PM +0200, Martin Zaharinov wrote: > > On 9 Dec 2020, at 18:40, Guillaume Nault wrote: > > On Wed, Dec 09, 2020 at 04:47:52PM +0200, Martin Zaharinov wrote: > >> Hi All > >> > >> I have problem with latest kernel release &g

Re: Urgent: BUG: PPP ioctl Transport endpoint is not connected

ppp); > + spin_unlock_bh(>downl); No, nested locks have to be released in the reverse order they were acquired. > But in stable kernel is : > > spin_unlock_bh(>downl); > ppp_unlock(ppp); This is correct, and has been correctly backported to 4.14-stable. > > On 9 Dec 2020, a

Re: Urgent: BUG: PPP ioctl Transport endpoint is not connected

On Wed, Dec 09, 2020 at 09:12:18PM +0200, Martin Zaharinov wrote: > > > > On 9 Dec 2020, at 20:10, Guillaume Nault wrote: > > > > On Wed, Dec 09, 2020 at 06:57:44PM +0200, Martin Zaharinov wrote: > >>> On 9 Dec 2020, at 18:40, Guillaume Nault wrote: >

Re: [PATCH] flow_dissector: work around stack frame size warning

gt; I now see 552 bytes of stack usage for fl_classify(), plus 528 bytes > for fl_mask_lookup(). > > Fixes: 58cff782cc55 ("flow_dissector: Parse multiple MPLS Label Stack > Entries") > Signed-off-by: Arnd Bergmann > Sorry, I didn't see that, as my .config has CONF

Re: [PATCH] net: l2tp: mark expected switch fall-through

nla_put_u16(skb, L2TP_ATTR_UDP_DPORT, > ntohs(inet->inet_dport))) > goto nla_put_failure; > - /* NOBREAK */ > + /* fall through */ > case L2TP_ENCAPTYPE_IP: > Nit: extra whitespace before '*/' (just couldn't restrain myself from noticing). Acked-by: Guillaume Nault

Re: kernel BUG at net/core/skbuff.c:LINE! (2)

On Tue, Jan 16, 2018 at 04:21:40PM +0800, Xin Long wrote: > ipv4 tunnels don't really set dev->hard_header_len properly, > we may should fix it in pppoe by using needed_headroom, > as what it doesn't in arp_create. > I'm a bit in doubt about which device needs to be fixed. Should ip_gre set

Re: [PATCH 1/1] l2tp: cleanup l2tp_tunnel_delete calls

rn value > warnings. > > Kill these now useless casts. > Acked-by: Guillaume Nault

Re: KASAN: use-after-free Read in remove_wait_queue (2)

On Tue, May 22, 2018 at 08:29:58PM -0700, Eric Biggers wrote: > On Fri, May 18, 2018 at 06:02:23PM +0200, Guillaume Nault wrote: > > On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote: > > > [+ppp list and maintainer] > > > > > > This is a bug in ppp_

Re: [PATCH] ppp: remove the PPPIOCDETACH ioctl

On Tue, May 22, 2018 at 08:59:52PM -0700, Eric Biggers wrote: > From: Eric Biggers > > The PPPIOCDETACH ioctl effectively tries to "close" the given ppp file > before f_count has reached 0, which is fundamentally a bad idea. It > does check 'f_count < 2', which excludes concurrent operations on

Re: [PATCH v2] ppp: remove the PPPIOCDETACH ioctl

fix would have made it clear that this patch was fixing some released code and should be considered for -stable backport. Reviewed-by: Guillaume Nault Tested-by: Guillaume Nault

Re: [PATCH 2/2] l2tp: Add Protocol field compression

On Fri, Dec 14, 2018 at 11:12:42PM +0200, Sam Protsenko wrote: > When Protocol Field Compression (PFC) is enabled, the "Protocol" field > in PPP packet should be transmitted without leading 0x00. See section > 6.5 in RFC 1661 for details. Let's compress protocol field if needed, > the same way

Re: [PATCH] l2tp: Add protocol field decompression

On Fri, Dec 14, 2018 at 07:59:21PM +0200, Sam Protsenko wrote: > When Protocol Field Compression (PFC) is enabled, the "Protocol" field > in PPP packet will be received without leading 0x00. See section 6.5 in > RFC 1661 for details. So let's decompress protocol field if needed, the > same way

Re: [PATCH] l2tp: Add protocol field decompression

On Sun, Dec 16, 2018 at 08:36:42PM +0200, Sam Protsenko wrote: > Hi Guillaume, > > On Sun, Dec 16, 2018 at 6:29 PM Guillaume Nault wrote: > > > > If you all agree, can we please revert this patch and properly > > implement PFC in ppp_generic.c? > > How abou

Re: [PATCH 2/2] l2tp: Add Protocol field compression

On Sun, Dec 16, 2018 at 08:46:19PM +0200, Sam Protsenko wrote: > Hi Guillaume, > > On Sun, Dec 16, 2018 at 6:30 PM Guillaume Nault wrote: > > > > On Fri, Dec 14, 2018 at 11:12:42PM +0200, Sam Protsenko wrote: > > > When Protocol Field Compression (PFC) is

Re: [PATCH] ppp: Move PFC decompression to PPP generic layer

On Wed, Dec 19, 2018 at 02:08:08AM +0200, Sam Protsenko wrote: > Extract "Protocol" field decompression code from transport protocols to > PPP generic layer, where it actually belongs. As a consequence, this > patch fixes incorrect place of PFC decompression in L2TP driver (when > it's not

Re: [PATCH v2] ppp: Move PFC decompression to PPP generic layer

d, deflate, > mppe). It looks like there is no easy way to get rid of that, so it was > decided to leave it as is, but provide those cases with appropriate > comments instead. > Thanks a lot for taking care of all these particular cases. Reviewed-by: Guillaume Nault Just a side n

Re: [PATCH 4.4 063/114] l2tp: hold socket before dropping lock in l2tp_ip{, 6}_recv()

> > [ Upstream commit a3c18422a4b4e108bcf6a2328f48867e1003fd95 ] > > Socket must be held while under the protection of the l2tp lock; there > is no guarantee that sk remains valid after the read_unlock_bh() call. > > Same issue for l2tp_ip and l2tp_ip6. > > Signed-off-by: Guillau

Re: [PATCH 4.4 063/114] l2tp: hold socket before dropping lock in l2tp_ip{, 6}_recv()

On Fri, Nov 09, 2018 at 08:28:56AM -0800, Greg Kroah-Hartman wrote: > On Fri, Nov 09, 2018 at 04:33:32PM +0100, Guillaume Nault wrote: > > On Thu, Nov 08, 2018 at 01:51:18PM -0800, Greg Kroah-Hartman wrote: > > > 4.4-stable review patch. If anyone has any objections, please

Re: [PATCH 3.2 000/102] 3.2.64-rc1 review

On Sat, Nov 01, 2014 at 10:28:02PM +, Ben Hutchings wrote: > This is the start of the stable review cycle for the 3.2.64 release. > There are 102 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. >

Re: [PATCH 4.4 00/60] 4.4.40-stable review

On Wed, Jan 04, 2017 at 09:46:45PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.40 release. > There are 60 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

Re: net/l2tp: use-after-free write in l2tp_ip6_close

On Mon, Nov 07, 2016 at 11:35:26PM +0100, Andrey Konovalov wrote: > Hi, > > I've got the following error report while running the syzkaller fuzzer: > > == > BUG: KASAN: use-after-free in l2tp_ip6_close+0x239/0x2a0 at addr >

Re: probably serious conntrack/netfilter panic, 4.8.14, timers and intel turbo

Cc: netfilter-de...@vger.kernel.org, I'm afraid I'll need some help for this case. On Sat, Dec 17, 2016 at 09:48:13PM +0200, Denys Fedoryshchenko wrote: > Hi, > > I posted recently several netfilter related crashes, didn't got any answers, > one of them started to happen quite often on loaded

Re: [PATCH net-next v5 2/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

On Wed, Apr 05, 2017 at 05:00:07PM -0700, R. Parameswaran wrote: > > Change-set here uses the new kernel function, kernel_sock_ip_overhead(), > to factor the outer IP overhead on the L2TP tunnel socket (including > IP Options, if any) when calculating the default MTU for an Ethernet > pseudowire,

Re: [PATCH net-next v5 2/2] L2TP:Adjust intf MTU, add underlay L3, L2 hdrs.

On Tue, Apr 11, 2017 at 09:39:58AM -0700, R Parameswaran wrote: > Hi Guillaume, > > On Tue, Apr 11, 2017 at 3:40 AM, Guillaume Nault wrote: > > On Wed, Apr 05, 2017 at 05:00:07PM -0700, R. Parameswaran wrote: > >> > >> Change-set here uses the new kernel

Re: [PATCH net-next v1 1/1] L2TP device MTU setup - tunnel socket needs a lock

tures to derive the > socket's IP overhead. Thanks. Tested-by: Guillaume Nault BTW, you don't need to add "v1" for the first version of a patch. There's also no need for numbering pathes when there's only one in the series. And we normally prefix the commit message with ": ". For th

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote: > static int ppp_open(struct inode *inode, struct file *file) > { > /* >* This could (should?) be enforced by the permissions on /dev/ppp. >*/ > if (!capable(CAP_NET_ADMIN)) > return -EPERM; >

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 03, 2016 at 12:35:12PM +0200, Richard Weinberger wrote: > On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault wrote: > > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote: > >> static int ppp_open(struct inode *inode,

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote: > On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote: > > On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault > > wrote: > > > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote: > >

Re: net/ppp: use-after-free in ppp_unregister_channel

On Wed, Mar 16, 2016 at 11:14:42PM +0800, Baozeng Ding wrote: > Dear all, > I've got the following use-after-free report while running syzkaller > fuzzer. Unfortunately no reproducer. It was found in the Linux kernel > version(4.4, on commit 9638685e32af961943b679fcb72d4ddd458eb18f). > >

Re: [Linux 4.2-rc8+...v4.3-rc2] REGRESSION: ppp: circular locking dependency detected: [pppd] ppp_dev_uninit() | rtnl_lock()

On Wed, Sep 23, 2015 at 08:06:16AM +0200, Sedat Dilek wrote: > Without reverting the below culprit ppp patch... > > commit/?id=8cb775bc0a34dc596837e7da03fd22c747be618b > ("ppp: fix device unregistration upon netns deletion") > > ...I have an unstable Internet connection via

Re: [Linux 4.2-rc8+...v4.3-rc2] REGRESSION: ppp: circular locking dependency detected: [pppd] ppp_dev_uninit() | rtnl_lock()

On Wed, Sep 23, 2015 at 11:21:50PM +0200, Sedat Dilek wrote: > On Wed, Sep 23, 2015 at 10:46 PM, Sedat Dilek wrote: > > On Wed, Sep 23, 2015 at 12:38 PM, Guillaume Nault > > wrote: > > Do you mind to send a proper patch with subject-line and commit-message? > >

Re: [BUG] net/ppp: A use after free in ppp_unregister_channe

On Thu, Mar 11, 2021 at 08:34:44PM +0800, lyl2...@mail.ustc.edu.cn wrote: > File: drivers/net/ppp/ppp_generic.c > > In ppp_unregister_channel, pch could be freed in ppp_unbridge_channels() > but after that pch is still in use. Inside the function ppp_unbridge_channels, > if "pchbb == pch" is true

Re: [BUG] net/ppp: A use after free in ppp_unregister_channe

On Fri, Mar 12, 2021 at 10:12:58AM +, Tom Parkin wrote: > Thanks for the report! > > On Thu, Mar 11, 2021 at 20:34:44 +0800, lyl2...@mail.ustc.edu.cn wrote: > > File: drivers/net/ppp/ppp_generic.c > > > > In ppp_unregister_channel, pch could be freed in ppp_unbridge_channels() > > but after

Re: Re: [BUG] net/ppp: A use after free in ppp_unregister_channe

On Fri, Mar 12, 2021 at 10:47:53PM +0800, lyl2...@mail.ustc.edu.cn wrote: > > > > > -原始邮件- > > 发件人: "Tom Parkin" > > 发送时间: 2021-03-12 18:12:58 (星期五) > > 收件人: lyl2...@mail.ustc.edu.cn > > 抄送: pau...@samba.org, da...@davemloft.net, linux-...@vger.kernel.org, > > net...@vger.kernel.org,

Re: linux-next: manual merge of the net-next tree with the net tree

On Mon, Feb 15, 2021 at 11:43:54AM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > tools/testing/selftests/net/forwarding/tc_flower.sh > > between commit: > > d2126838050c ("flow_dissector: fix TTL and TOS dissection on IPv4