This TLS bug is still present. See more recent report here:
https://syzkaller.appspot.com/text?tag=CrashReport&x=10613446a0
On Wed, Nov 28, 2018 at 11:58:37AM +0100, 'Alexander Potapenko' via
syzkaller-bugs wrote:
> On Sat, Nov 24, 2018 at 12:02 AM Ard Biesheuvel
> wrote:
> >
> > (+ TLS mai
On Thu, Oct 22, 2020 at 10:00:44AM -0700, Nick Desaulniers wrote:
> On Thu, Oct 22, 2020 at 9:40 AM Matthew Wilcox wrote:
> >
> > On Thu, Oct 22, 2020 at 04:35:17PM +, David Laight wrote:
> > > Wait...
> > > readv(2) defines:
> > > ssize_t readv(int fd, const struct iovec *iov, int iovcn
On Wed, Apr 07, 2021 at 07:39:20PM +0800, Hangbin Liu wrote:
> As the cryptos(BLAKE2S, Curve25519, CHACHA20POLY1305) in WireGuard are not
> FIPS certified, the WireGuard module should be disabled in FIPS mode.
>
> Signed-off-by: Hangbin Liu
I think you mean "FIPS allowed", not "FIPS certified"?
On Thu, Apr 08, 2021 at 07:58:08PM +0800, Hangbin Liu wrote:
> On Thu, Apr 08, 2021 at 09:06:52AM +0800, Hangbin Liu wrote:
> > > Also, couldn't you just consider WireGuard to be outside your FIPS module
> > > boundary, which would remove it from the scope of the certification?
> > >
> > > And how
On Mon, Jan 08, 2018 at 12:58:11PM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Mon, Jan 8, 2018 at 12:55 PM, Dmitry Vyukov wrote:
> > On Mon, Jan 8, 2018 at 12:43 PM, syzbot
> > wrote:
> >> Hello,
> >>
> >> syzkaller hit the following crash on
> >> f66faae2f80a45feafc04ce63ef744ac4b6e8
On Thu, Jan 04, 2018 at 02:58:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 0e08c463db387a2adcb0243b15ab868a73f87807
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
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 'cxgb4-fix-dump-collection-when-firmware-crashed'
>
> Unfortunately, I don't have any r
On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:c1c07416cdd4 Merge tag 'kbuild-fixes-v4.17' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13d5de4780
> kernel
On Wed, May 09, 2018 at 07:23:41AM +0200, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Wed, May 9, 2018 at 7:05 AM, Eric Biggers wrote:
> > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following cr
On Wed, Jan 03, 2018 at 10:53:14PM -0800, Eric Dumazet wrote:
> On Wed, 2018-01-03 at 21:13 -0800, Eric Dumazet wrote:
> > Note: all commands must start from beginning of the line in the email body.
> >
> > I guess skb_probe_transport_header() should be hardened to reject malicious
> > packets giv
On Fri, Jan 05, 2018 at 02:07:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 8a4816cad00bf14642f0ed6043b32d29a05006ce
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console ou
On Thu, Feb 15, 2018 at 04:22:28PM -0800, Cong Wang wrote:
> On Tue, Feb 13, 2018 at 10:48 AM, Dmitry Vyukov wrote:
> > On Mon, Oct 30, 2017 at 7:41 PM, Cong Wang wrote:
> >> On Mon, Oct 30, 2017 at 8:34 AM, syzbot
> >>
> >> wrote:
> >>> Hello,
> >>>
> >>> syzkaller hit the following crash on
>
On Wed, Jan 31, 2018 at 05:58:01PM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 3da90b159b146672f830bcd2489dd3a1f4e9e089 (Wed Jan 31 03:07:32 2018 +)
> Merge tag 'f2fs-for-4.16-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs
>
> So
On Tue, Jan 02, 2018 at 03:58:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 61233580f1f33c50e159c50e24d80ffd2ba2e06b
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console ou
On Sat, Mar 31, 2018 at 04:01:02PM -0700, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on bpf-next commit
> 1379ef828a18d8f81c526b25e4d5685caa2cfd65 (Thu Mar 29 22:09:44 2018 +)
> Merge branch 'bpf-sockmap-ingress'
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid
On Mon, Mar 05, 2018 at 04:18:00PM +0100, Paolo Abeni wrote:
> On Mon, 2018-03-05 at 00:21 -0800, syzbot wrote:
> > Hello,
> >
> > syzbot hit the following crash on upstream commit
> > 5fbdefcf685defd8bc5a8f37b17538d25c58d77a (Fri Mar 2 21:05:20 2018 +)
> > Merge branch 'parisc-4.16-1' of
>
[+bpf maintainers and netdev]
On Mon, Nov 06, 2017 at 03:56:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 5cb0512c02ecd7e6214e912e4c150f4219ac78e0
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .conf
On Mon, Mar 12, 2018 at 10:57:07AM -0700, Eric Biggers wrote:
> On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> > Eric Biggers wrote:
> >
> > > Fix it by limiting option strings (combined name + value) to a much more
> > > reasonable 128 bytes.
Hi Michael,
On Tue, Mar 27, 2018 at 11:06:14PM +0100, Michael Young wrote:
> NFS mounts stopped working on one of my computers after a kernel update from
> 4.15.3 to 4.15.4. I traced the problem to the commit
> [46e8d06e423c4f35eac7a8b677b713b3ec9b0684] crypto: hash - prevent using
> keyed hashes
On Wed, Mar 28, 2018 at 09:00:14AM +0100, M A Young wrote:
> On Tue, 27 Mar 2018, Eric Biggers wrote:
>
> > Hi Michael,
> >
> > On Tue, Mar 27, 2018 at 11:06:14PM +0100, Michael Young wrote:
> > > NFS mounts stopped working on one of my computers after a kernel u
On Wed, Mar 28, 2018 at 11:46:28AM -0400, J. Bruce Fields wrote:
> On Tue, Mar 27, 2018 at 03:29:50PM -0700, Eric Biggers wrote:
> > Hi Michael,
> >
> > On Tue, Mar 27, 2018 at 11:06:14PM +0100, Michael Young wrote:
> > > NFS mounts stopped working on one of my c
mounts in some cases.
Fix it by removing the incorrect call to crypto_ahash_init().
Reported-by: Michael Young
Fixes: 9fa68f620041 ("crypto: hash - prevent using keyed hashes without setting
key")
Fixes: fffdaef2eb4a ("gss_krb5: Add support for rc4-hmac encryption")
Cc: sta...@vge
[+bpf and tls maintainers]
On Wed, Jul 03, 2019 at 04:23:34PM +0100, Al Viro wrote:
> On Wed, Jul 03, 2019 at 03:40:00PM +0100, Al Viro wrote:
> > On Wed, Jul 03, 2019 at 02:43:07PM +0800, Hillf Danton wrote:
> >
> > > > This is very much *NOT* fine.
> > > > 1) trylock can fail from any n
On Thu, Jun 27, 2019 at 12:01:23PM -0700, Eric Biggers wrote:
> On Thu, Jun 27, 2019 at 11:19:51AM -0700, John Fastabend wrote:
> > Eric Biggers wrote:
> > > [+TLS maintainers]
> > >
> > > Very likely a net/tls bug, not a crypto bug.
> > >
> &
From: Eric Biggers
Switch the DO_ONCE() macro from the deprecated jump label API to the new
one. The new one is more readable, and for DO_ONCE() it also makes the
generated code more icache-friendly: now the one-time initialization
code is placed out-of-line at the jump target, rather than at
From: Eric Biggers
commit bbb03029a899 ("strparser: Generalize strparser") added more
function pointers to 'struct strp_callbacks'; however, kcm_attach() was
not updated to initialize them. This could cause the ->lock() and/or
->unlock() function pointers to be set to
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the distinct crashes that syzbot has seen in the last week, I've manually
marked 8 of them as possibly being bugs in the "net/bpf" subsystem
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the distinct crashes that syzbot has seen in the last week, I've manually
marked 6 of them as possibly being bugs in the "net/tls" subsystem
From: Eric Biggers
syzbot reported:
BUG: KMSAN: uninit-value in capi_write+0x791/0xa90
drivers/isdn/capi/capi.c:700
CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call
From: Eric Biggers
Commit 9060cb719e61 ("net: crypto set sk to NULL when af_alg_release.")
fixed a use-after-free in sockfs_setattr() when an AF_ALG socket is
closed concurrently with fchownat(). However, it ignored that many
other proto_ops::release() methods don't set sock-
Hi Eric,
On Fri, Feb 22, 2019 at 09:45:35AM -0800, Eric Dumazet wrote:
>
>
> On 02/21/2019 02:13 PM, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Commit 9060cb719e61 ("net: crypto set sk to NULL when af_alg_release.")
> > fixed a use-after-fre
On Fri, Jun 08, 2018 at 06:11:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:7170e6045a6a strparser: Add __strp_unpause and use it in k..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=114236af80
> kernel
On Thu, Jul 12, 2018 at 06:44:55AM -0400, Boris Pismenny wrote:
> It seems to me that the crash here is due to write_space being called after
> the close system call. Maybe the correct solution is to move the TX software
> state to be released in sk_destruct. As we already do for the device state
>
On Tue, Jun 19, 2018 at 10:34:01PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:ba4dbdedd3ed Merge tag 'jfs-4.18' of git://github.com/klei..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=112e9ce440
> kernel
On Fri, Sep 28, 2018 at 06:09:03AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:1042caa79e93 net-ipv4: remove 2 always zero parameters fro..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13fff71140
> kernel
On Sat, Jul 07, 2018 at 06:29:03PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:526674536360 Add linux-next specific files for 20180706
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=17e6396840
> kernel co
On Thu, Dec 20, 2018 at 02:55:03AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:6531e115b7ab Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13b0bd5d40
> kernel confi
On Tue, Oct 23, 2018 at 03:13:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:ca9eb48fe01f Merge tag 'regulator-v5.0' of git://git.kerne..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1482a93940
> kernel
On Fri, Oct 12, 2018 at 12:58:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:771b65e89c8a Add linux-next specific files for 20181011
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=167d237640
> kernel co
On Mon, Jul 09, 2018 at 04:49:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:6508b6781be0 tcp: cleanup copied_seq and urg_data in tcp_d..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1256e6dc40
> kernel conf
On Fri, Sep 15, 2017 at 09:07:51PM -0700, Eric Biggers wrote:
> On Tue, Aug 22, 2017 at 02:44:41PM -0400, Hannes Frederic Sowa wrote:
> > Eric Biggers writes:
> >
> > > From: Eric Biggers
> > >
> > > Switch the DO_ONCE() macro from the deprecated jum
From: Eric Biggers
Switch the DO_ONCE() macro from the deprecated jump label API to the new
one. The new one is more readable, and for DO_ONCE() it also makes the
generated code more icache-friendly: now the one-time initialization
code is placed out-of-line at the jump target, rather than at
On Thu, Jun 14, 2018 at 05:14:30PM +0100, David Howells wrote:
> The fix seems to work, but the use of kstrtoul():
>
> ret = kstrtoul(eq, 10, &derrno);
>
> is incorrect since the buffer can't been modified to block out the next
> argument if there is one, so the following fails:
>
>
From: Eric Biggers
My recent fix for dns_resolver_preparse() printing very long strings was
incomplete, as shown by syzbot which still managed to hit the
WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:
precision 50001 too large
WARNING: CPU: 7 PID:
On Tue, 24 Oct 2017 08:15:01 -0700, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> b9f1f1ce866c28e3d9b86202441b220244754a69
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console
On Wed, Feb 14, 2018 at 02:45:05PM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Wed, Dec 6, 2017 at 1:50 PM, Dmitry Vyukov wrote:
> > On Fri, Oct 27, 2017 at 11:18 PM, Cong Wang
> > wrote:
> >> On Thu, Oct 26, 2017 at 11:00 PM, Dmitry Vyukov wrote:
> >>> On Thu, Oct 26, 2017 at 7:58 P
On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> Eric Biggers wrote:
>
> > Fix it by limiting option strings (combined name + value) to a much more
> > reasonable 128 bytes. The exact limit is arbitrary, but currently the
> > only recognized option is fo
On Mon, Mar 12, 2018 at 02:04:12PM -0700, Tom Herbert wrote:
> Need to lock lower socket in order to provide mutual exclusion
> with kcm_unattach.
>
> Fixes: ab7ac4eb9832e32a09f4e804 ("kcm: Kernel Connection Multiplexor module")
> Signed-off-by: Tom Herbert
> ---
Is this fixing the syzbot-report
On Mon, Mar 12, 2018 at 02:25:41PM -0700, Tom Herbert wrote:
> On Mon, Mar 12, 2018 at 2:09 PM, Eric Biggers wrote:
> > On Mon, Mar 12, 2018 at 02:04:12PM -0700, Tom Herbert wrote:
> >> Need to lock lower socket in order to provide mutual exclusion
> >> with kc
On Fri, Mar 23, 2018 at 01:21:22PM -0700, Eric Biggers wrote:
> On Mon, Mar 12, 2018 at 10:57:07AM -0700, Eric Biggers wrote:
> > On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> > > Eric Biggers wrote:
> > >
> > > > Fix it by limiting opti
On Sat, Nov 11, 2017 at 07:56:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> d9e0e63d9a6f88440eb201e1491fcf730272c706
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw
On Mon, Dec 25, 2017 at 05:45:00PM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> fba961ab29e5ffb055592442808bb0f7962e05da
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw c
On Wed, Nov 29, 2017 at 10:08:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 1d3b78bbc6e983fabb3fbf91b76339bf66e4a12c
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console ou
On Wed, Nov 01, 2017 at 09:50:18PM +0300, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Wed, Nov 1, 2017 at 9:48 PM, syzbot
>
> wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 720bbe532b7c8f5613b48dea627fc58ed9ace707
> > git://git.cmpxchg.org/linux-mmots.git/master
> > compile
On Thu, Jan 18, 2018 at 01:34:02AM -0800, syzbot wrote:
> syzbot has found reproducer for the following crash on linux-next commit
> a362f6d2cdbd089dd7040ba66dcb0ad276a20cf7 (Thu Jan 18 07:07:54 2018 +)
> Add linux-next specific files for 20180118
>
> So far this crash happened 185 times on li
[+RDS list and maintainer]
On Sat, Dec 09, 2017 at 12:50:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console o
On Fri, Dec 15, 2017 at 11:51:01PM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console ou
On Mon, Apr 02, 2018 at 12:20:35PM -0700, Eric Biggers wrote:
> On Fri, Mar 23, 2018 at 01:21:22PM -0700, Eric Biggers wrote:
> > On Mon, Mar 12, 2018 at 10:57:07AM -0700, Eric Biggers wrote:
> > > On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> >
From: Eric Biggers
Adding a dns_resolver key whose payload contains a very long option name
resulted in that string being printed in full. This hit the WARN_ONCE()
in set_precision() during the printk(), because printk() only supports a
precision of up to 32767 bytes:
precision 100 too
On Tue, Apr 17, 2018 at 01:43:16PM -0400, David Miller wrote:
> From: Eric Biggers
> Date: Mon, 16 Apr 2018 14:29:22 -0700
>
> > From: Eric Biggers
> >
> > Adding a dns_resolver key whose payload contains a very long option name
> > resulted in that string bei
On Tue, Apr 17, 2018 at 02:24:37PM -0400, David Miller wrote:
> From: Eric Biggers
> Date: Tue, 17 Apr 2018 11:23:40 -0700
>
> > Can you queue this up for stable too? syzbot has been hitting this on older
> > kernel versions.
>
> If you want a patch bound for stable,
From: Eric Biggers
Adding a dns_resolver key whose payload contains a very long option name
resulted in that string being printed in full. This hit the WARN_ONCE()
in set_precision() during the printk(), because printk() only supports a
precision of up to 32767 bytes:
precision 100 too
Hi Mark,
On Tue, Feb 27, 2018 at 04:43:13PM +, Mark Rutland wrote:
> Hi,
>
> As a heads-up, while fuzzing v4.16-rc3 on arm64 with Syzkaller, I hit a
> system hang which I was able to minize to the reproducer below. It looks
> like the system hang is an artifact of Syzkaller using panic_on_war
From: Eric Biggers
Adding a dns_resolver key whose payload contains a very long option name
resulted in that string being printed in full. This hit the WARN_ONCE()
in set_precision() during the printk(), because printk() only supports a
precision of up to 32767 bytes:
precision 100 too
On Tue, Feb 27, 2018 at 06:34:19PM -0800, Eric Dumazet wrote:
> On Tue, 2018-02-27 at 17:49 -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Adding a dns_resolver key whose payload contains a very long option name
> > resulted in that string being pri
From: Eric Biggers
Adding a dns_resolver key whose payload contains a very long option name
resulted in that string being printed in full. This hit the WARN_ONCE()
in set_precision() during the printk(), because printk() only supports a
precision of up to 32767 bytes:
precision 100 too
From: Eric Biggers
If a message sent to a PF_KEY socket ended with one of the extensions
that takes a 'struct sadb_address' but there were not enough bytes
remaining in the message for the ->sa_family member of the 'struct
sockaddr' which is supposed to follow, then ve
From: Eric Biggers
If a message sent to a PF_KEY socket ended with an incomplete extension
header (fewer than 4 bytes remaining), then parse_exthdrs() read past
the end of the message, into uninitialized memory. Fix it by returning
-EINVAL in this case.
Reproducer:
#include
On Fri, Dec 29, 2017 at 05:49:34PM +0100, Dmitry Vyukov wrote:
> On Fri, Dec 29, 2017 at 5:48 PM, Alexander Potapenko
> wrote:
> > Hi all,
> >
> > KMSAN reports a use of uninitialized value on the following program:
> >
> > ==
> > // autogenerated by syzkaller (http://gith
On Wed, May 23, 2018 at 11:56:36AM -0400, David Miller wrote:
> From: Guillaume Nault
> Date: Wed, 23 May 2018 15:57:08 +0200
>
> > I'd rather add
> > + if (cmd == PPPIOCDETACH) {
> > + err = -EINVAL;
> > + goto out;
> > + }
> >
> > Making PPPIOCDETACH unknown to ppp_gene
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 the
file since they would only be possible wit
From: Eric Biggers
My recent fix for dns_resolver_preparse() printing very long strings was
incomplete, as shown by syzbot which still managed to hit the
WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:
precision 50001 too large
WARNING: CPU: 7 PID:
Hi Simon,
On Mon, Jun 11, 2018 at 11:40:23AM +0200, Simon Horman wrote:
> On Fri, Jun 08, 2018 at 09:20:37AM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > My recent fix for dns_resolver_preparse() printing very long strings was
> > incomplete, as shown by
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 3 of them as possibly being bugs in the "net/rxrpc" subs
27;ve tested that this fixes the syzbot bugs, but otherwise I don't
know of any way to test this code.
Eric Biggers (4):
llc: fix sk_buff leak in llc_sap_state_process()
llc: fix sk_buff leak in llc_conn_service()
llc: fix another potential sk_buff leak in llc_ui_sendmsg()
llc: f
From: Eric Biggers
syzbot reported:
BUG: memory leak
unreferenced object 0x888116270800 (size 224):
comm "syz-executor641", pid 7047, jiffies 4294947360 (age 13.860s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 0
From: Eric Biggers
If llc_conn_state_process() sees that llc_conn_service() put the skb on
a list, it will drop one fewer references to it. This is wrong because
the current behavior is that llc_conn_service() never consumes a
reference to the skb.
The code also makes the number of skb
From: Eric Biggers
syzbot reported:
BUG: memory leak
unreferenced object 0x88811eb3de00 (size 224):
comm "syz-executor559", pid 7315, jiffies 4294943019 (age 10.300s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 0
From: Eric Biggers
All callers of llc_conn_state_process() except llc_build_and_send_pkt()
(via llc_ui_sendmsg() -> llc_ui_send_data()) assume that it always
consumes a reference to the skb. Fix this caller to do the same.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by:
On Thu, Sep 10, 2020 at 10:04:24AM +0530, Anmol Karn wrote:
> Prevent hci_phy_link_complete_evt() from dereferencing 'hcon->amp_mgr'
> as NULL. Fix it by adding pointer check for it.
>
> Reported-and-tested-by: syzbot+0bef568258653cff2...@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot
Looks like the tls subsystem is encrypting uninitialized memory again.
+tls maintainers and netdev.
On Thu, Sep 10, 2020 at 07:09:24AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:3b3ea602 x86: add failure injection to get/put/clear_user
> git tree:
On Tue, Sep 15, 2020 at 10:43:31AM +0530, Anmol Karn wrote:
> On Mon, Sep 14, 2020 at 08:26:55PM +0100, Matthew Wilcox wrote:
> > On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:
> > > On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:
> > > > On Mon, Sep 14, 2020 at 12:47:2
On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Jaegeuk Kim
> Cc: Chao Yu
> Signed-off-by: Ira Weiny
On Sat, Oct 10, 2020 at 01:39:54AM +0100, Matthew Wilcox wrote:
> On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > > The kmap() calls in this FS are localized to a single thread. To avoid
&
On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> >
> > And I still don't really understand. After this patchset, there is still
> > code
> > nearly identical to the above (doing a temporary mapping just for a memcpy)
> > that
> > would still be using kmap_atomic().
>
> I don't unde
On Mon, Aug 03, 2020 at 06:12:33PM +0100, Russell King - ARM Linux admin wrote:
> Dear syzbot,
>
> Please explain why you are spamming me with all these reports - four so
> far. I don't understand why you think I should be doing anything with
> these.
>
> Thanks.
syzbot just uses get_maintainer
On Mon, Aug 03, 2020 at 06:32:24PM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Aug 03, 2020 at 10:21:04AM -0700, Eric Biggers wrote:
> > On Mon, Aug 03, 2020 at 06:12:33PM +0100, Russell King - ARM Linux admin
> > wrote:
> > > Dear syzbot,
> > >
On Mon, Jul 20, 2020 at 02:47:13PM +0200, Christoph Hellwig wrote:
> Hi Dave,
>
> setsockopt is the last place in architecture-independ code that still
> uses set_fs to force the uaccess routines to operate on kernel pointers.
>
> This series adds a new sockptr_t type that can contained either a
On Mon, Jul 20, 2020 at 02:47:16PM +0200, Christoph Hellwig wrote:
> Add a uptr_t type that can hold a pointer to either a user or kernel
> memory region, and simply helpers to copy to and from it. For
> architectures like x86 that have non-overlapping user and kernel
> address space it just is a
On Mon, Jul 20, 2020 at 05:55:06PM +0200, Ahmed S. Darwish wrote:
> Hi,
>
> This is v4 of the seqlock patch series:
>
>[PATCH v1 00/25]
>
> https://lore.kernel.org/lkml/20200519214547.352050-1-a.darw...@linutronix.de
>
>[PATCH v2 00/06] (bugfixes-only, merged)
>
> https://lore.ke
On Mon, Jul 20, 2020 at 07:43:22PM +0200, Christoph Hellwig wrote:
> On Mon, Jul 20, 2020 at 09:37:48AM -0700, Eric Biggers wrote:
> > How does this not introduce a massive security hole when
> > CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE?
> >
> > AFAICS, user
On Sun, Jul 12, 2020 at 05:03:00PM -0400, Peilin Ye wrote:
> qrtr_tun_write_iter() is dereferencing `ZERO_SIZE_PTR`s when `from->count`
> equals to zero. Fix it by rejecting zero-length kzalloc() requests.
>
> This patch fixes the following syzbot bug:
>
>
> https://syzkaller.appspot.com/bug
On Mon, Jul 13, 2020 at 11:18:36AM +0100, Christoph Hellwig wrote:
> On Fri, Jul 10, 2020 at 10:34:19PM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
>
> This is not a crash, but a WARN_ONCE. A pre-existing one that just
> slightly changed the printed message recen
On Thu, Aug 27, 2020 at 12:23:55PM +0530, Himadri Pandya wrote:
> The buffer size is 2 Bytes and we expect to receive the same amount of
> data. But sometimes we receive less data and run into uninit-was-stored
> issue upon read. Hence modify the error check on the return value to match
> with the
From: Eric Biggers
CRYPTO_MSG_GETALG in NLM_F_DUMP mode sometimes doesn't return all
registered crypto algorithms, because it doesn't support incremental
dumps. crypto_dump_report() only permits itself to be called once, yet
the netlink subsystem allocates at most ~64 KiB for the
On Tue, Sep 25, 2018 at 04:55:59PM +0200, Jason A. Donenfeld wrote:
>
> It is intended that this entire patch series enter the kernel through
> DaveM's net-next tree. Subsequently, WireGuard patches will go through
> DaveM's net-next tree, while Zinc patches will go through Greg KH's tree.
>
Why
On Thu, Sep 27, 2018 at 11:35:39PM +0200, Jason A. Donenfeld wrote:
> Hi Eric,
>
> On Thu, Sep 27, 2018 at 8:29 PM Eric Biggers wrote:
> > Why is Herbert Xu's existing crypto tree being circumvented, especially for
> > future patches (the initial merge isn't
On Sun, Jan 28, 2018 at 10:58:01AM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> c4e0ca7fa24137e372d6135fe16e8df8e123f116 (Fri Jan 26 23:10:50 2018 +)
> Merge tag 'riscv-for-linus-4.15-maintainers' of
> git://git.kernel.org/pub/scm/linux/kernel/git/palme
On Wed, Mar 21, 2018 at 09:00:01AM -0700, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 3215b9d57a2c75c4305a3956ca303d7004485200 (Wed Mar 21 00:44:27 2018 +)
> Merge tag 'clk-fixes-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> syzbot
From: Eric Biggers
It's possible to crash the kernel in several different ways by sending
messages to the SMC_PNETID generic netlink family that are missing the
expected attributes:
- Missing SMC_PNETID_NAME => null pointer dereference when comparing
names.
- Missing SMC_PNETID
1 - 100 of 190 matches
Mail list logo
