syzbot has bisected this issue to:
commit 6f8c8f3c31015808100ee54fc471ff5dffdf1734
Author: Bartosz Golaszewski
Date: Thu Aug 8 08:01:44 2019 +
hwmon: pmbus: ucd9000: remove unneeded include
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1550298a90
start commit: 47e
fix the compile warnings of 'strncpy' output truncated before
terminating nul copying N bytes from a string of the same length
Signed-off-by: Luo bin
Reported-by: kernel test robot
---
V2~V1:
- remove strncpy
V0~V1:
- use the strlen()+1 pattern consistently
.../net/ethernet/huawei/hinic/hinic_
On 2020/8/8 20:50, David Laight wrote:
> From: luobin (L)
>> Sent: 08 August 2020 04:37
>>
>> On 2020/8/7 17:32, David Laight wrote:
>>> From: Luo bin
Sent: 07 August 2020 03:09
fix the compile warnings of 'strncpy' output truncated before
terminating nul copying N bytes from a
On 2020/8/8 14:44, Kees Cook wrote:
> On Fri, Aug 07, 2020 at 08:42:43PM -0700, David Miller wrote:
>> From: "luobin (L)"
>> Date: Sat, 8 Aug 2020 11:36:42 +0800
>>
>>> On 2020/8/7 17:32, David Laight wrote:
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> b/drivers/net/e
On 2020/8/8 11:42, David Miller wrote:
> From: "luobin (L)"
> Date: Sat, 8 Aug 2020 11:36:42 +0800
>
>> On 2020/8/7 17:32, David Laight wrote:
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
index c6adc776f3c8..1ec8
1. Added a skb->len check
This driver expects upper layers to include a pseudo header of 1 byte
when passing down a skb for transmission. This driver will read this
1-byte header. This patch added a skb->len check before reading the
header to make sure the header exists.
2. Added needed_headroom
On Sat, Aug 08, 2020 at 01:52:37PM -0700, Linus Torvalds wrote:
> On Sat, Aug 8, 2020 at 1:47 PM George Spelvin wrote:
>> I *just* finished explaining, using dribs and drabs of entropy allows an
>> *information theoretical attack* which *no* crypto can prevent.
>
> The key word here being "theore
Remove redundant fops null check
Fixes: 30c8bd5aa8b2c ("net: Introduce generic failover module")
Signed-off-by: Gaurav Singh
---
net/core/failover.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/failover.c b/net/core/failover.c
index b5cd3c727285..63213347f51c 1006
On Sat, Aug 8, 2020 at 3:28 PM George Spelvin wrote:
>
> It's not a theoretical hole, it's a very real one. Other than the cycles
> to do the brute-force part, it's not even all that complicated. The
> theory part is that it's impossible to patch.
We'll just disagree.
I'm really fed up with se
On Sat, Aug 08, 2020 at 12:49:30PM -0700, Andy Lutomirski wrote:
> I don't care about throwing this stuff away. My plan (not quite
> implemented yet) is to have a percpu RNG stream and to never to anything
> resembling mixing anything in. The stream is periodically discarded and
> reinitialized
On Sat, Aug 08, 2020 at 09:18:27PM +0200, Florian Westphal wrote:
> Can't we keep prandom_u32 as-is...? Most of the usage, esp. in the
> packet schedulers, is fine.
>
> I'd much rather have a prandom_u32_hashed() or whatever for
> those cases where some bits might leak to the outside and then con
On Sat, Aug 08, 2020 at 11:19:01AM -0700, Linus Torvalds wrote:
> If siphash is a good enough hash to make the pseudo-random state hard
> to guess, then it's also a good enough hash to hide the small part of
> the fast-pool we mix in.
No!
No, no, a thousand times no.
I *just* finished explaining
On Mon, Aug 03, 2020 at 09:33:20PM +0100, Edward Cree wrote:
> Several parts of the EF100 architecture are parameterised (to allow
> varying capabilities on FPGAs according to resource constraints), and
> these parameters are exposed to the driver through a TLV-encoded
> region of the BAR.
> For
On Sat, Aug 08, 2020 at 07:44:51PM +0200, Willy Tarreau wrote:
> On Sat, Aug 08, 2020 at 03:26:28PM +, George Spelvin wrote:
>> So any discussion of reseeding begins by *assuming* an attacker has
>> captured the PRNG state. If we weren't worried about this possibility,
>> we wouldn't need to r
From: Kees Cook
[ Upstream commit 47e33c05f9f07cac3de833e531bcac9ae052c7ca ]
When SECCOMP_IOCTL_NOTIF_ID_VALID was first introduced it had the wrong
direction flag set. While this isn't a big deal as nothing currently
enforces these bits in the kernel, it should be defined correctly. Fix
the def
From: Kees Cook
[ Upstream commit 47e33c05f9f07cac3de833e531bcac9ae052c7ca ]
When SECCOMP_IOCTL_NOTIF_ID_VALID was first introduced it had the wrong
direction flag set. While this isn't a big deal as nothing currently
enforces these bits in the kernel, it should be defined correctly. Fix
the def
From: Kees Cook
[ Upstream commit 47e33c05f9f07cac3de833e531bcac9ae052c7ca ]
When SECCOMP_IOCTL_NOTIF_ID_VALID was first introduced it had the wrong
direction flag set. While this isn't a big deal as nothing currently
enforces these bits in the kernel, it should be defined correctly. Fix
the def
On Sat, Aug 08, 2020 at 10:07:51AM -0700, Andy Lutomirski wrote:
>>- Cryptographically strong ChaCha, batched
>>- Cryptographically strong ChaCha, with anti-backtracking.
>
> I think we should just anti-backtrack everything. With the "fast key
> erasure" construction, already implemented
Hello!
Thanks to Jason for getting this conversation back on track.
Yes: in general, {} or a partial initializer /will/ zero padding bits.
However, there is a bug in some versions of GCC where {} will /not/ zero
padding bits; actually, Jason's test program in this mail
https://lore.kernel.org/
From: linmiaohe
Date: Sat, 8 Aug 2020 16:23:10 +0800
> From: Miaohe Lin
>
> Convert the uses of fallthrough comments to fallthrough macro.
>
> Signed-off-by: Miaohe Lin
Applied.
From: Thierry Reding
Date: Fri, 7 Aug 2020 09:36:32 +0200
> From: Thierry Reding
>
> Query the USB device's device tree node when looking for a MAC address.
> The struct device embedded into the struct net_device does not have a
> device tree node attached at all.
>
> The reason why this went
Hello,
syzbot found the following issue on:
HEAD commit:c0842fbc random32: move the pseudo-random 32-bit definitio..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=127a8d6690
kernel config: https://syzkaller.appspot.com/x/.config?x=cf567e8c7428377e
das
From: linmiaohe
Date: Thu, 6 Aug 2020 19:57:18 +0800
> From: Miaohe Lin
>
> Use helper function ip_is_fragment() to check ip fragment.
>
> Signed-off-by: Miaohe Lin
Applied.
From: linmiaohe
Date: Thu, 6 Aug 2020 19:54:19 +0800
> From: Miaohe Lin
>
> The out_fs jump label has nothing to do but goto out.
>
> Signed-off-by: Miaohe Lin
Applied.
From: linmiaohe
Date: Thu, 6 Aug 2020 19:53:16 +0800
> From: Miaohe Lin
>
> We should fput() file iff FDPUT_FPUT is set. So we should set fput_needed
> accordingly.
>
> Fixes: 00e188ef6a7e ("sockfd_lookup_light(): switch to fdget^W^Waway from
> fget_light")
> Signed-off-by: Miaohe Lin
Appli
From: linmiaohe
Date: Thu, 6 Aug 2020 19:52:24 +0800
> From: Miaohe Lin
>
> Use helper function fdput() to fput() the file iff FDPUT_FPUT is set.
>
> Signed-off-by: Miaohe Lin
Applied.
Hi Florian,
On Sat, Aug 08, 2020 at 09:18:27PM +0200, Florian Westphal wrote:
> > struct rnd_state {
> > - __u32 s1, s2, s3, s4;
> > + siphash_key_t key;
> > + uint64_t counter;
> > };
>
> Does the siphash_key really need to be percpu?
I don't think so, I was really exploring a quick and
From: Nick Desaulniers
Date: Thu, 6 Aug 2020 11:29:39 -0700
> From: Jakub Kicinski
>
> When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
> compiler to deduce a case where _val can only have the value of -1 at
> compile time. Specifically,
>
> /* struct bpf_insn: _s32 imm
From: Johan Hovold
Date: Thu, 6 Aug 2020 17:37:53 +0200
> A recent commit introduced a late error path in phy_device_create()
> which fails to release the device name allocated by dev_set_name().
>
> Fixes: 13d0ab6750b2 ("net: phy: check return code when requesting PHY driver
> module")
> Cc:
From: Johannes Berg
Date: Wed, 5 Aug 2020 16:03:20 +0200
> This is something I'd been thinking about for a while; we already
> have NLA_MIN_LEN, NLA_BINARY (with a max len), and NLA_EXACT_LEN,
> but in quite a few places (as you can see in the last patch here)
> we need a range, and we already h
On Sat, Aug 8, 2020 at 1:47 PM George Spelvin wrote:
>
> I *just* finished explaining, using dribs and drabs of entropy allows an
> *information theoretical attack* which *no* crypto can prevent.
The key word here being "theoretical".
The other key word is "reality".
We will have to agree to di
On Sat, Aug 8, 2020 at 1:08 PM George Spelvin wrote:
>
> So assuming that once per interrupt equals "often" is completely false.
That's not what people are assuming.
They are assuming it's "unpredictable".
Guys, look up the real and true meaning of "random" some day.
Guess what? It at no point
> On Aug 8, 2020, at 12:03 PM, George Spelvin wrote:
>
> On Sat, Aug 08, 2020 at 10:07:51AM -0700, Andy Lutomirski wrote:
>>> - Cryptographically strong ChaCha, batched
>>> - Cryptographically strong ChaCha, with anti-backtracking.
>>
>> I think we should just anti-backtrack everything.
I'm quite annoyed at the way that this discussion has drifted away from
the main problem, which is that f227e3ec3b5c is broken and needs reverted.
The original bug report is accurate, and it's a critical issue.
My proposed fix is described (patch imminent) below.
THE PROBLEM:
The reseeding desi
Willy Tarreau wrote:
> diff --git a/include/linux/random.h b/include/linux/random.h
> index 9ab7443bd91b..9e22973b207c 100644
> --- a/include/linux/random.h
> +++ b/include/linux/random.h
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -117,7 +118,
Attention
Unilever Austria Chain urgently looking for a reliable supplier that can supply
and delivery hospital equipments; we have been commissioned to source the
equipment's for hospital upgrade due to the ongoing COVID-19 PANDEMIC in
Vienna, therefore, would like to extend an
Invitation B
On Sat, Aug 08, 2020 at 11:19:01AM -0700, Linus Torvalds wrote:
> On Sat, Aug 8, 2020 at 10:45 AM Willy Tarreau wrote:
> >
> >
> > WIP: random32: use siphash with a counter for prandom_u32
>
> siphash is good.
>
> But no:
>
> > --- a/drivers/char/random.c
> > +++ b/drivers/char/random.c
> >
On Sat, Aug 08, 2020 at 12:38 AM CEST, Stanislav Fomichev wrote:
> I'm getting some garbage in bytes 8 and 9 when doing conversion
> from sockaddr_in to sockaddr_in6 (leftover from AF_INET?).
> Let's explicitly clear the higher bytes.
>
> Signed-off-by: Stanislav Fomichev
> ---
> tools/testing/se
On Thu, Aug 06, 2020 at 10:45:52AM -0600, David Ahern wrote:
> On 8/2/20 8:49 AM, Ido Schimmel wrote:
> > On Thu, Jun 11, 2020 at 10:36:59PM -0600, David Ahern wrote:
> >> On 6/11/20 6:32 PM, Yi Yang (杨燚)-云服务集团 wrote:
> >>> David, thank you so much for confirming it can't, I did read your cumulus
On Sat, Aug 8, 2020 at 10:45 AM Willy Tarreau wrote:
>
>
> WIP: random32: use siphash with a counter for prandom_u32
siphash is good.
But no:
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1277,7 +1277,6 @@ void add_interrupt_randomness(int irq, int irq_flags)
>
>
On Sat, Aug 8, 2020 at 10:07 AM Andy Lutomirski wrote:
>
>
> > On Aug 8, 2020, at 8:29 AM, George Spelvin wrote:
> >
>
> > And apparently switching to the fastest secure PRNG currently
> > in the kernel (get_random_u32() using ChaCha + per-CPU buffers)
> > would cause too much performance penalty
On Sat, Aug 08, 2020 at 10:07:51AM -0700, Andy Lutomirski wrote:
>
> > On Aug 8, 2020, at 8:29 AM, George Spelvin wrote:
> >
>
> > And apparently switching to the fastest secure PRNG currently
> > in the kernel (get_random_u32() using ChaCha + per-CPU buffers)
> > would cause too much performan
The underlying Ethernet device may request necessary tailroom to be
allocated by setting needed_tailroom. This driver should also set
needed_tailroom to request the tailroom needed by the underlying
Ethernet device to be allocated.
Cc: Willem de Bruijn
Cc: Martin Schiller
Signed-off-by: Xie He
On Sat, Aug 08, 2020 at 03:26:28PM +, George Spelvin wrote:
> So any discussion of reseeding begins by *assuming* an attacker has
> captured the PRNG state. If we weren't worried about this possibility,
> we wouldn't need to reseed in the first place!
Sure, but what matters is the time it tak
On Sat, Aug 8, 2020 at 10:07 AM Gaurav Singh wrote:
>
> This PR fixes a possible segmentation violation.
>
> In function: ip6_xmit(), we have
> const struct ipv6_pinfo *np = inet6_sk(sk); which returns NULL
> unconditionally (regardless sk being NULL or not).
>
> In include/linux/ipv6.h:
>
> stat
> On Aug 8, 2020, at 8:29 AM, George Spelvin wrote:
>
> And apparently switching to the fastest secure PRNG currently
> in the kernel (get_random_u32() using ChaCha + per-CPU buffers)
> would cause too much performance penalty.
Can someone explain *why* the slow path latency is particularly r
This PR fixes a possible segmentation violation.
In function: ip6_xmit(), we have
const struct ipv6_pinfo *np = inet6_sk(sk); which returns NULL
unconditionally (regardless sk being NULL or not).
In include/linux/ipv6.h:
static inline struct ipv6_pinfo * inet6_sk(const struct sock *__sk)
{
On 8/7/20 8:06 PM, Andrew Lunn wrote:
> So i personally don't think netdev statistics is a good idea, i doubt
> it scales.
+1
On 8/8/20 1:16 AM, Paul Hollinsky wrote:
> xdp->txq was uninitialized and could be used from within a bpf program.
The verifier prevents access to txq except by programs of type
BPF_XDP_DEVMAP and those can not be run via xdp generic. ie., generic
can not access txq.
>
> https://syzkaller.appsp
On Thu, Aug 06, 2020 at 07:21:21PM +0300, Adrian Pop wrote:
> Hi Andrew!
>
> Should I resubmit v3 after I delete the code that has to do with page
> 0x10 and 0x11?
Yes please.
Andrew
From: Eric Dumazet
> Sent: 07 August 2020 19:29
>
> On 8/7/20 2:18 AM, David Laight wrote:
> > From: Eric Dumazet
> >> Sent: 06 August 2020 23:21
> >>
> >> On 7/22/20 11:09 PM, Christoph Hellwig wrote:
> >>> Rework the remaining setsockopt code to pass a sockptr_t instead of a
> >>> plain user poi
From: luobin (L)
> Sent: 08 August 2020 04:37
>
> On 2020/8/7 17:32, David Laight wrote:
> > From: Luo bin
> >> Sent: 07 August 2020 03:09
> >>
> >> fix the compile warnings of 'strncpy' output truncated before
> >> terminating nul copying N bytes from a string of the same length
> >>
> >> Signed-
> On Fri, Aug 7, 2020 at 3:20 PM Paul E. McKenney wrote:
> >
> > On Fri, Aug 07, 2020 at 04:47:56PM -0400, Joel Fernandes wrote:
> > > Hi,
> > > Adding more of us working on RCU as well. Johan from another team at
> > > Google discovered a likely issue in openswitch, details below:
> > >
> > > On
Hello,
syzbot found the following issue on:
HEAD commit:5631c5e0 Merge tag 'xfs-5.9-merge-7' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15c2193490
kernel config: https://syzkaller.appspot.com/x/.config?x=afba7c06f91e56eb
das
From: Miaohe Lin
Convert the uses of fallthrough comments to fallthrough macro.
Signed-off-by: Miaohe Lin
---
net/socket.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index c61f036d24f5..f4d5998bdcba 100644
--- a/net/socket.c
+++ b/net/
xdp->txq was uninitialized and could be used from within a bpf program.
https://syzkaller.appspot.com/bug?id=a6e53f8e9044ea456ea1636be970518ae6ba7f62
Signed-off-by: Paul Hollinsky
---
net/core/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7df6
On Fri, Aug 07, 2020 at 05:02:15PM -0700, John Stultz wrote:
> On Fri, Aug 7, 2020 at 3:18 PM Kees Cook wrote:
> >
> > On Fri, Aug 07, 2020 at 01:29:24PM -0700, John Stultz wrote:
> > > On Thu, Jul 9, 2020 at 11:28 AM Kees Cook wrote:
> > > >
> > > > Duplicate the cleanups from commit 2618d530dd8
57 matches
Mail list logo
