On Fri, Apr 9, 2021 at 6:47 AM Simo Sorce wrote:
> > depends on m || !CRYPTO_FIPS
> >
> > but I am a bit concerned that the rather intricate kconfig
> > dependencies between the generic and arch-optimized versions of those
> > drivers get complicated even further.
>
> Actually this is the opposi
On Fri, Apr 9, 2021 at 2:08 AM Hangbin Liu wrote:
> After offline discussion with Herbert, here is
> what he said:
>
> """
> This is not a problem in RHEL8 because the Crypto API RNG replaces /dev/random
> in FIPS mode.
> """
So far as I can see, this isn't the case in the kernel sources I'm
read
On Fri, Apr 09, 2021 at 10:49:07AM +0800, Hangbin Liu wrote:
> On Thu, Apr 08, 2021 at 08:44:35PM -0600, Jason A. Donenfeld wrote:
> > Since it's just a normal module library, you can simply do this in the
> > module_init function, rather than deep within registration
> >
Hi Hangbin,
On Thu, Apr 8, 2021 at 8:41 PM Hangbin Liu wrote:
> I agree that the best way is to disable the crypto modules in FIPS mode.
> But the code in lib/crypto looks not the same with crypto/. For modules
> in crypto, there is an alg_test() to check if the crytpo is FIPS allowed
> when do r
On Thu, Apr 8, 2021 at 7:55 AM Simo Sorce wrote:
> > I'm not sure this makes so much sense to do _in wireguard_. If you
> > feel like the FIPS-allergic part is actually blake, 25519, chacha, and
> > poly1305, then wouldn't it make most sense to disable _those_ modules
> > instead? And then the var
Hi Hangbin,
On Wed, Apr 7, 2021 at 5:39 AM Hangbin Liu wrote:
>
> As the cryptos(BLAKE2S, Curve25519, CHACHA20POLY1305) in WireGuard are not
> FIPS certified, the WireGuard module should be disabled in FIPS mode.
I'm not sure this makes so much sense to do _in wireguard_. If you
feel like the FI
On Thu, Mar 18, 2021 at 1:33 AM Yunsheng Lin wrote:
> > That offer definitely still stands. Generalization sounds like a lot of fun.
> >
> > Keep in mind though that it's an eventually consistent queue, not an
> > immediately consistent one, so that might not match all use cases. It
> > works with
On 3/17/21, Toke Høiland-Jørgensen wrote:
> Cong Wang writes:
>
>> On Mon, Mar 15, 2021 at 2:07 PM Jakub Kicinski wrote:
>>>
>>> I thought pfifo was supposed to be "lockless" and this change
>>> re-introduces a lock between producer and consumer, no?
>>
>> It has never been truly lockless, it us
Hey Linus,
Thanks for the patch and sorry for the delay in reviewing it. Seeing
the basic scaffolding for getting netlink notifiers working with
WireGuard is enlightening; it looks surprisingly straightforward.
There are three classes of things that are interesting to receive
notifications for:
c: David Ahern
Cc: Jakub Kicinski
Cc: Steffen Klassert
Fixes: 803381f9f117 ("Merge branch
'icmp-account-for-NAT-when-sending-icmps-from-ndo-layer'")
Signed-off-by: Jason A. Donenfeld
---
v1->v2:
- Expanded Cc list and justification.
- No code changes.
net/ipv4/ip_
On Sat, Feb 27, 2021 at 12:29 AM Willem de Bruijn
wrote:
>
> On Fri, Feb 26, 2021 at 5:39 PM Jason A. Donenfeld wrote:
> >
> > On Fri, Feb 26, 2021 at 10:25 PM Willem de Bruijn
> > wrote:
> > >
> > > On Thu, Feb 25, 2021 at 6:46 PM Jason A. Donenfeld
On Fri, Feb 26, 2021 at 10:25 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 25, 2021 at 6:46 PM Jason A. Donenfeld wrote:
> >
> > There were a few remaining tunnel drivers that didn't receive the prior
> > conversion to icmp{,v6}_ndo_send. Knowing now that this could
e
imperative to have these all converted. So this commit goes through the
remaining cases that I could find and does a boring translation to the
ndo variety.
Cc: Willem de Bruijn
Signed-off-by: Jason A. Donenfeld
---
net/ipv4/ip_tunnel.c | 5 ++---
net/ipv4/ip_vti.c | 6 +++---
net/ip
: a2b78e9b2cac ("sunvnet: generate ICMP PTMUD messages for smaller port
MTUs")
Reported-by: SinYu
Reviewed-by: Willem de Bruijn
Link:
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by: Jason A. Donenfeld
---
Changes v4-
The condition here was incorrect: a non-neon fallback implementation is
available on arm32 when NEON is not supported.
Reported-by: Ilya Lipnitskiy
Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/Kconfig | 2 +-
1 file
e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/device.c | 12 ++---
drivers/net/wireguard/device.h | 15 +++---
drivers/net/wireguard/peer.c | 28 ---
drivers/net/wireguard/peer.h
uture planned work, this is a useful regression to avoid.
Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
tools/testing/selftests/wireguard/netns.sh | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git
: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/peer.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireguard/peer.h b/drivers/net/wireguard/peer.h
index 23af40922997..aaff8de6e34b 10
net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/device.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index cd51a2afa28e..8502e1b083ff 100644
-
different endianness.
Since then, this assignment was already split up into separate statements;
just the cast survived.
Signed-off-by: Jann Horn
Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/socket.c | 4 ++--
: Antonio Quartulli
Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/device.c | 2 +-
drivers/net/wireguard/socket.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireguard/
Jason
Antonio Quartulli (1):
wireguard: avoid double unlikely() notation when using IS_ERR()
Jann Horn (1):
wireguard: socket: remove bogus __be32 annotation
Jason A. Donenfeld (5):
wireguard: selftests: test multiple parallel streams
wireguard: peer: put frequently used members above cac
: a2b78e9b2cac ("sunvnet: generate ICMP PTMUD messages for smaller port
MTUs")
Reported-by: SinYu
Cc: Willem de Bruijn
Cc: David L Stevens
Cc: David S. Miller
Link:
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by:
On Thu, Feb 18, 2021 at 11:06 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 18, 2021 at 3:39 PM Jason A. Donenfeld wrote:
> >
> > The icmp{,v6}_send functions make all sorts of use of skb->cb, casting
>
> Again, if respinning, please briefly describe the specific bugg
On Thu, Feb 18, 2021 at 9:37 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 18, 2021 at 3:25 PM Jason A. Donenfeld wrote:
> >
> > On Thu, Feb 18, 2021 at 9:16 PM Willem de Bruijn
> > wrote:
> > >
> > > On Thu, Feb 18, 2021 at 12:58 PM Jason A. Donenfeld
&
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by: Jason A. Donenfeld
---
Changes v2->v3:
- Fix build errors with CONFIG_IPV6=m
drivers/net/gtp.c | 1 -
include/linux/icmpv6.h | 26 --
include/linux/ipv6.h | 1 -
include/net
On Thu, Feb 18, 2021 at 9:16 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 18, 2021 at 12:58 PM Jason A. Donenfeld wrote:
> >
> > On Thu, Feb 18, 2021 at 5:34 PM Willem de Bruijn
> > wrote:
> > > Thanks for respinning.
> > >
> > > Making ipv4
On Thu, Feb 18, 2021 at 8:08 PM Jakub Kicinski wrote:
>
> On Thu, 18 Feb 2021 13:30:53 +0100 Jason A. Donenfeld wrote:
> > The icmp{,v6}_send functions make all sorts of use of skb->cb, assuming
> > the skb to have come directly from the inet layer. But when the packet
&
On Thu, Feb 18, 2021 at 5:34 PM Willem de Bruijn
wrote:
> Thanks for respinning.
>
> Making ipv4 and ipv6 more aligned is a good goal, but more for
> net-next than bug fixes that need to be backported to many stable
> branches.
>
> Beyond that, I'm not sure this fixes additional cases vs the previ
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by: Jason A. Donenfeld
---
drivers/net/gtp.c | 1 -
include/linux/icmpv6.h | 26 --
include/linux/ipv6.h | 1 -
include/net/icmp.h | 6 +-
net/ipv4/icmp.c|
Hi Willem,
On Thu, Feb 18, 2021 at 3:57 PM Willem de Bruijn
wrote:
>
> On Thu, Feb 18, 2021 at 7:31 AM Jason A. Donenfeld wrote:
> >
> > The icmp{,v6}_send functions make all sorts of use of skb->cb, assuming
>
> Indeed that also casts skb->cb, to read IP6CB(sk
:
https://lore.kernel.org/netdev/CAF=yd-lof116ahub6rme8vb8zpnrrnotdqhobex+bvoa8as...@mail.gmail.com/T/
Signed-off-by: Jason A. Donenfeld
---
drivers/net/gtp.c | 1 -
include/linux/icmpv6.h | 6 +-
include/net/icmp.h | 6 +-
net/ipv4/icmp.c| 2 ++
net/ipv6/ip6_icmp.c| 2
On 2/18/21, Willem de Bruijn wrote:
> On Wed, Feb 17, 2021 at 5:56 PM Jason A. Donenfeld wrote:
>>
>> Hi Willem,
>>
>> On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
>> wrote:
>> > A vmlinux image might help. I couldn't find one for this kerne
Hi Willem,
On Wed, Feb 17, 2021 at 11:27 PM Willem de Bruijn
wrote:
> A vmlinux image might help. I couldn't find one for this kernel.
https://data.zx2c4.com/icmp_send-crash-e03b4a42-706a-43bf-bc40-1f15966b3216.tar.xz
has .debs with vmlinuz in there, which you can extract to vmlinux, as
well as
Hi Netdev & Willem,
I've received a report of stack corruption -- via the stack protector
check -- in icmp_send. I was sent a vmcore, and was able to extract
the OOPS from there. However, I've been unable to produce the bug and
I don't see where it'd be in the code. That might point to a more
sini
On Tue, Feb 16, 2021 at 6:46 PM Jason A. Donenfeld wrote:
>
> Hi Catalin,
>
> On Tue, Feb 16, 2021 at 6:28 PM Catalin Marinas
> wrote:
> > Adding Jason and Ard. It may be a use-after-free in the wireguard
> > driver.
>
> Thanks for sending this my way. Note: to
Hi Catalin,
On Tue, Feb 16, 2021 at 6:28 PM Catalin Marinas wrote:
> Adding Jason and Ard. It may be a use-after-free in the wireguard
> driver.
Thanks for sending this my way. Note: to my knowledge, Ard doesn't
work on wireguard.
> > hlist_add_head include/linux/list.h:883 [inline]
> > enque
Hey Linus,
My email server has been firewalled from vger.kernel.org until today,
so I didn't see the original until this v2 was sent today. My
apologies. I'll review this first thing on Monday.
Jason
Hi Dmitry,
On Mon, Dec 21, 2020 at 10:14 AM Dmitry Vyukov wrote:
> Hi Jason,
>
> Thanks for looking into this.
>
> Reading clang docs for ubsan:
>
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
> -fsanitize=object-size: An attempt to potentially use bytes which the
> optimizer can
Hmm, on first glance, I'm not sure I'm seeing the bug:
On Sun, Dec 20, 2020 at 5:54 PM syzbot
wrote:
> UBSAN: object-size-mismatch in ./include/linux/skbuff.h:2021:28
> member access within address 85889cc2 with insufficient space
> for an object of type 'struct sk_buff'
> __skb_queue_be
On Thu, Dec 10, 2020 at 9:56 AM Antonio Quartulli wrote:
>
> The definition of IS_ERR() already applies the unlikely() notation
> when checking the error status of the passed pointer. For this
> reason there is no need to have the same notation outside of
> IS_ERR() itself.
>
> Clean up code by re
Hi Yang,
On Tue, Dec 1, 2020 at 10:31 AM Yang Yingliang wrote:
>
> After commit cf124db566e6 ("net: Fix inconsistent teardown and..."),
> priv_destruct() doesn't call free_netdev() in driver, we use
> dev->needs_free_netdev to indicate whether free_netdev() should be
> called on release path.
> T
g churn. If arch
> maintainers want to clean them up, please go ahead.
>
> While I was here, I also moved __must_check to compiler_attributes.h
> from compiler_types.h
For the wireguard test harness change:
Acked-by: Jason A. Donenfeld
of ll header,
>* exported to higher levels.
>*
> @@ -2198,7 +2198,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct
> net_device *dev,
> if (!net_eq(dev_net(dev), sock_net(sk)))
> goto drop;
>
> - if (dev->header_ops) {
> + if (dev_has_header(dev)) {
> if (sk->sk_type != SOCK_DGRAM)
> skb_push(skb, skb->data - skb_mac_header(skb));
> else if (skb->pkt_type == PACKET_OUTGOING) {
Thanks for fixing this. Patch seems correct to me.
Acked-by: Jason A. Donenfeld
On Tue, Nov 17, 2020 at 9:32 AM Ard Biesheuvel wrote:
> If you are going back to the drawing board with in-kernel acceleration
> for OpenVPN
As far as I can tell, they're mostly after compatibility with their
existing userspace stuff. Otherwise, if they were going back to the
drawing board, they
Nack.
This API is meant to take simple integers, so that programmers can use
atomic64_t with it and have safe nonces. I'm also interested in
preserving the API's ability to safely encrypt more than 4 gigs of
data at once. Passing a buffer also encourages people to use
randomized nonces, which isn'
On Tue, Nov 10, 2020 at 6:20 PM Greg KH wrote:
>
> On Tue, Nov 10, 2020 at 01:29:41PM +0100, Jason A. Donenfeld wrote:
> > Note that this requires
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=46d6c5ae953cc0be38efd0e469284df7c4328cf8
> >
Note that this requires
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=46d6c5ae953cc0be38efd0e469284df7c4328cf8
And that commit should be backported to every kernel ever, since the
bug is so old.
struct net_device *dev)
> --
> 2.29.2
Looks fine to me.
Reviewed-by: Jason A. Donenfeld
On Fri, Oct 30, 2020 at 8:23 PM Pablo Neira Ayuso wrote:
>
> On Thu, Oct 29, 2020 at 03:56:04AM +0100, Jason A. Donenfeld wrote:
> > Hi Pablo,
> >
> > This series fixes a bug in the route_me_harder family of functions with
> > regards to tunnel interfaces. The first
As a historical note, this code goes all the way back to Rusty in
2.3.14, where it looked like this:
#ifdef CONFIG_NETFILTER
/* To preserve the cute illusion that a locally-generated packet can
be mangled before routing, we actually reroute if a hook altered
the packet. -RR */
static int route
On Thu, Oct 29, 2020 at 1:01 PM Jason A. Donenfeld wrote:
>
> As a historical note, this code goes all the way back to Rusty in
> 2.3.14, where it looked like this:
Grrr, typo. 2.3.15.
ant condition inside our test suite, since wireguard was where
the bug was discovered.
Reported-by: Chen Minqiang
Signed-off-by: Jason A. Donenfeld
---
tools/testing/selftests/wireguard/netns.sh | 8
tools/testing/selftests/wireguard/qemu/kernel.config | 2 ++
2 files changed,
e of __ip_queue_xmit().
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jason A. Donenfeld
---
include/linux/netfilter_ipv4.h | 2 +-
include/linux/netfilter_ipv6.h | 10 +-
net/ipv4/netfilter.c | 8 +---
net/ipv4/netfilter/iptable_mangle
e on it to help with that.
Thanks,
Jason
Jason A. Donenfeld (2):
wireguard: selftests: check that route_me_harder packets use the right
sk
netfilter: use actual socket sk rather than skb sk when routing harder
include/linux/netfilter_ipv4.h | 2 +-
include/linux/n
we no longer need to track test_num in counter_test.c.
> But deleting the /*1*/ test_num comments means git (with the default
> threshold) no longer recognizes that the file was moved.
>
> Signed-off-by: Daniel Latypov
> Cc: Jason A. Donenfeld
> Cc: David Miller
> Cc:
ge down to
csum_partial_copy_generic()")
Cc: Al Viro
Signed-off-by: Jason A. Donenfeld
---
arch/powerpc/lib/checksum_32.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S
index ec5cd2dede35..27d9070617df 100644
--- a/arch/powerpc/lib/checksum_
On Thu, Oct 15, 2020 at 12:53 AM Linus Torvalds
wrote:
>
> On Wed, Oct 14, 2020 at 3:51 PM Linus Torvalds
> wrote:
> >
> > I think it's this instruction:
> >
> > addir1,r1,16
> >
> > that should be removed from the function exit, because Al removed the
> >
> > - stwur1,-16(r
On Thu, Oct 15, 2020 at 12:51 AM Linus Torvalds
wrote:
>
> On Wed, Oct 14, 2020 at 3:27 PM Jason A. Donenfeld wrote:
> >
> > This patch is causing crashes in WireGuard's CI over at
> > https://www.wireguard.com/build-status/ . Apparently sending a simple
> >
Hi Al,
On Fri, Jul 24, 2020 at 02:25:46AM +0100, Al Viro wrote:
> From: Al Viro
>
> ... and get rid of the pointless fallback in the wrappers. On error it used
> to zero the unwritten area and calculate the csum of the entire thing. Not
> wanting to do it in assembler part had been very reason
Hey Pablo,
In 60a3815da702fd9e4759945f26cce5c47d3967ad, you added another enum
value to nf_inet_hooks:
--- a/include/uapi/linux/netfilter.h
+++ b/include/uapi/linux/netfilter.h
@@ -45,6 +45,7 @@ enum nf_inet_hooks {
NF_INET_FORWARD,
NF_INET_LOCAL_OUT,
NF_INET_POST_ROUTING,
+
eue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Reported-by: syzbot
Reported-by: Eric Dumazet
Link:
https://lore.kernel.org/wireguard/20200908145911.4090480-1-eduma...@google.com/
Fi
hat's part of this series as a
companion.
Both of these contain Fixes: tags and are good candidates for stable.
Jason A. Donenfeld (2):
wireguard: noise: take lock when removing handshake entry from table
wireguard: peerlookup: take lock before checking hash in replace
operation
dri
tency across table mutator
functions, and this might let me rest slightly easier at night.
Suggested-by: Eric Dumazet
Link:
https://lore.kernel.org/wireguard/20200908145911.4090480-1-eduma...@google.com/
Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Signed-off-by: Jason A. D
Hey Eric,
On Tue, Sep 8, 2020 at 4:59 PM Eric Dumazet wrote:
>
> syzbot got a NULL dereference in wg_index_hashtable_replace() [1]
>
> Issue here is that right after checking hlist_unhashed(&old->index_hash)
> another cpu might have removed @old already from the hash.
>
> Since we are dealing wit
On Mon, Aug 24, 2020 at 10:07 PM Jason A. Donenfeld wrote:
> I believe that the bug Dan reported would easily be fixed as well by
> just setting dev->needs_free_netdev=true and removing the call to
> free_netdev(dev) in wg_destruct, in wireguard. If you think that this is
> the
quot;net: Fix inconsistent teardown and release of private
netdev state.")
Cc: David S. Miller
Signed-off-by: Jason A. Donenfeld
---
I believe that the bug Dan reported would easily be fixed as well by
just setting dev->needs_free_netdev=true and removing the call to
free_netdev(dev)
On Mon, Aug 24, 2020 at 4:15 PM Dan Carpenter wrote:
>
> Hello Jason A. Donenfeld,
>
> The patch e7096c131e51: "net: WireGuard secure network tunnel" from
> Dec 9, 2019, leads to the following static checker warning:
>
> net/core/dev.c:10103 netdev_run_t
On 8/20/20, David Miller wrote:
> From: "Jason A. Donenfeld"
> Date: Thu, 20 Aug 2020 11:13:49 +0200
>
>> It seems like if an eBPF program pushes on a VLAN tag or changes the
>> protocol or does any other modification, it will be treated in exactly
>> the s
On Wed, Aug 19, 2020 at 8:42 PM syzbot
wrote:
>
> syzbot has bisected this issue to:
>
> commit e7096c131e5161fa3b8e52a650d7719d2857adfd
> Author: Jason A. Donenfeld
> Date: Sun Dec 8 23:27:34 2019 +
>
> net: WireGuard secure network tunnel
&
On Thu, Aug 20, 2020 at 1:22 AM David Miller wrote:
>
> From: "Jason A. Donenfeld"
> Date: Sat, 15 Aug 2020 09:41:02 +0200
>
> > A user reported that packets from wireguard were possibly ignored by XDP
> > [1]. Another user reported that modifying packets from
On 8/17/20, Jesper Dangaard Brouer wrote:
> On Sun, 16 Aug 2020 15:29:37 -0700 (PDT)
> David Miller wrote:
>
>> From: "Jason A. Donenfeld"
>> Date: Sat, 15 Aug 2020 09:29:30 +0200
>>
>> > When an XDP program changes the ethernet header protocol fie
On Fri, Aug 14, 2020 at 11:27 PM David Miller wrote:
>
> From: "Jason A. Donenfeld"
> Date: Fri, 14 Aug 2020 23:04:56 +0200
>
> > What? No. It comes up repeatedly because people want to reuse their
> > XDP processing logic with layer 3 devices.
>
> XDP i
Jesper Dangaard Brouer
Cc: John Fastabend
Cc: Daniel Borkmann
Cc: David S. Miller
Signed-off-by: Jason A. Donenfeld
---
I had originally dropped this patch, but the issue kept coming up in
user reports, so here's a v4 of it. Testing of it is still rather slim,
but hopefully that will chan
eric XDP to handle if eth header was mangled")
Cc: Jesper Dangaard Brouer
Cc: David S. Miller
Signed-off-by: Jason A. Donenfeld
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7df6c9617321..151f1651439f 100644
--- a/net/core/de
On 8/14/20, Jakub Kicinski wrote:
> On Fri, 14 Aug 2020 08:56:48 +0200 Jason A. Donenfeld wrote:
>> On Thu, Aug 13, 2020 at 11:01 PM Jakub Kicinski wrote:
>> > > I had originally dropped this patch, but the issue kept coming up in
>> > > user reports, so here
On 8/14/20, David Miller wrote:
> From: "Jason A. Donenfeld"
> Date: Fri, 14 Aug 2020 09:30:48 +0200
>
>> @@ -4676,6 +4688,7 @@ static u32 netif_receive_generic_xdp(struct sk_buff
>> *skb,
>> (orig_bcast != is_multicast_ether_addr_64bits(eth->h_
e user is primarily concerned
with transformations to layer 3 and beyond.
[1] https://lore.kernel.org/wireguard/m5wzvk5--...@tuta.io/
Reported-by: Thomas Ptacek
Reported-by: Adhipati Blambangan
Cc: David Ahern
Cc: Toke Høiland-Jørgensen
Cc: Jakub Kicinski
Cc: Alexei Starovoitov
Signed-of
On Thu, Aug 13, 2020 at 11:01 PM Jakub Kicinski wrote:
> > I had originally dropped this patch, but the issue kept coming up in
> > user reports, so here's a v4 of it. Testing of it is still rather slim,
> > but hopefully that will change in the coming days.
>
> Here an alternative patch, untested
://lore.kernel.org/wireguard/m5wzvk5--...@tuta.io/
Reported-by: Thomas Ptacek
Reported-by: Adhipati Blambangan
Cc: David Ahern
Cc: Toke Høiland-Jørgensen
Cc: Jakub Kicinski
Cc: Alexei Starovoitov
Signed-off-by: Jason A. Donenfeld
---
I had originally dropped this patch, but the issue kept c
On Wed, Aug 5, 2020 at 6:07 PM wrote:
> That being said, it certainly is a certificational / theoretical
> weakness
random.c is filled with super suspicious things that are probably only
correct by accident, or only correct in practice, but in theory it's
just such a mess. Stupid example if I'm r
On Tue, Jul 28, 2020 at 10:07 AM David Laight wrote:
>
> From: Christoph Hellwig
> > Sent: 27 July 2020 17:24
> >
> > On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote:
> > > Maybe sockptr_advance should have some safety checks and sometimes
&g
r and copy_to_sockptr.
>
> Fixes: ba423fdaa589 ("net: add a new sockptr_t type")
> Reported-by: Jason A. Donenfeld
> Reported-by: Ido Schimmel
> Signed-off-by: Christoph Hellwig
> ---
> drivers/crypto/chelsio/chtls/chtls_main.c | 12 +---
On Mon, Jul 27, 2020 at 5:06 PM Christoph Hellwig wrote:
>
> On Mon, Jul 27, 2020 at 05:03:10PM +0200, Jason A. Donenfeld wrote:
> > Hi Christoph,
> >
> > On Thu, Jul 23, 2020 at 08:08:54AM +0200, Christoph Hellwig wrote:
> > > diff --git a/net/ipv4/ip_so
Hi Christoph,
On Thu, Jul 23, 2020 at 08:08:54AM +0200, Christoph Hellwig wrote:
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index da933f99b5d517..42befbf12846c0 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -1422,7 +1422,8 @@ int ip_setsockopt(stru
On Sun, Jun 28, 2020 at 2:04 PM Willem de Bruijn
wrote:
>
> On Sat, Jun 27, 2020 at 1:58 AM Jason A. Donenfeld wrote:
> >
> > Hi again Hans,
> >
> > A few remarks: although gre implements header_ops, it looks like
> > various parts of the networking st
Hey Cong,
I'm wondering if the below error is related to what you've been
looking at yesterday. AFAICT, there's a simple UaF on the attrbuf
passed to the start method. I recall recently you were working on the
locking in genetlink's family buffers and wound up mallocing some
things, so it seems li
parse_protocol, this returns zero, and sit rejects the
skb. So, this wires up the ip_tunnel handler for layer 3 packets for
that case.
Reported-by: Willem de Bruijn
Signed-off-by: Jason A. Donenfeld
---
net/ipv6/sit.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.
ocol -> parse_protocol
Without a valid parse_protocol, this returns zero, and wireguard then
rejects the skb. So, this wires up the ip_tunnel handler for layer 3
packets for that case.
Reported-by: Hans Wippel
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/device.c | 1 +
1
parse_protocol, this returns zero, and vti rejects the
skb. So, this wires up the ip_tunnel handler for layer 3 packets for
that case.
Signed-off-by: Jason A. Donenfeld
---
net/ipv4/ip_vti.c | 1 +
net/ipv6/ip6_vti.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/ip_vti.c b/net
arser function, as it is useful in standalone form too.
Signed-off-by: Jason A. Donenfeld
---
Changes v1->v2:
- [Willem] Remove added copyright header from v1.
include/net/ip_tunnels.h | 3 +++
net/ipv4/ip_tunnel_core.c | 18 ++
2 files changed, 21 insertions(+)
diff --git a/inc
parse_protocol, this returns zero, and ipip rejects the
skb. So, this wires up the ip_tunnel handler for layer 3 packets for
that case.
Signed-off-by: Jason A. Donenfeld
---
net/ipv4/ipip.c | 1 +
net/ipv6/ip6_tunnel.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/ipip.c b/n
col
Without a valid parse_protocol, this returns zero, and xfrmi rejects the
skb. So, this wires up the ip_tunnel handler for layer 3 packets for
that case.
Reported-by: Willem de Bruijn
Signed-off-by: Jason A. Donenfeld
---
net/xfrm/xfrm_interface.c | 2 ++
1 file changed, 2 insertions(+)
d
l, this returns zero, and the tun driver
then gives userspace bogus values that it can't deal with.
Note that this isn't the case with tap, because tap already benefits
from the shared infrastructure for ethernet headers. But with tun,
there's nothing.
Signed-off-by: Jason A. Don
aces
that stuck out as requiring it, and does a bit of cleanup.
This patchset seems like it's fixing real bugs, so it might be
appropriate for stable. But they're also very old bugs, so if you'd
rather not backport to stable, that'd make sense to me too.
Jason A. Donenfe
Now that wg_examine_packet_protocol has been added for general
consumption as ip_tunnel_parse_protocol, it's possible to remove
wg_examine_packet_protocol and simply use the new
ip_tunnel_parse_protocol function directly.
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/queue
Hey Dave, Willem,
Sorry for the delay in getting back to you; this weekend was spent
moving across the state again, so not much time for emails.
> We customarily don't add new Copyright lines for every change and
> fix made to existing files, please get rid of that.
Sure, no problem. I had done
Hi Dmitry,
On Sat, Jun 27, 2020 at 2:59 AM Dmitry Vyukov wrote:
> Hard to say. syzkaller frequently needs some time (days) to get
> reasonable coverage of new code.
> Is wg_netns_pre_exit executed synchronously in the context of a
> syscall? If not, then it won't be shown as covered. If yes, then
Now that wg_examine_packet_protocol has been added for general
consumption as ip_tunnel_parse_protocol, it's possible to remove
wg_examine_packet_protocol and simply use the new
ip_tunnel_parse_protocol function directly.
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/queue
ocol -> parse_protocol
Without a valid parse_protocol, this returns zero, and wireguard then
rejects the skb. So, this wires up the ip_tunnel handler for layer 3
packets for that case.
Reported-by: Hans Wippel
Signed-off-by: Jason A. Donenfeld
---
drivers/net/wireguard/device.c | 1 +
1
1 - 100 of 521 matches
Mail list logo
