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 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, 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 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 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 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 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
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 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
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
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, 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, 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 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 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 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 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 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
[+linux-wireless, Marcel Holtmann, and Denis Kenzior]
On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote:
> Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from
> a maintenance perspective, since it does not quite behave like other
> skciphers do in terms of key vs
ret = aes_expandkey(&ctx, key, key_len);
> + if (ret)
> + return ret;
>
> -out:
> - skcipher_request_free(req);
> - crypto_free_skcipher(tfm);
> - return ret;
> + aes_encrypt(&ctx, hkey, input);
> + memzero_explicit(&ctx, sizeof(ctx));
> + return 0;
> }
>
Otherwise this looks good. You can add:
Reviewed-by: Eric Biggers
- Eric
On Tue, Jun 16, 2020 at 08:02:58AM +0200, Steffen Klassert wrote:
> On Mon, Jun 15, 2020 at 03:13:15PM -0700, Eric Biggers wrote:
> > This series consolidates and modernizes the lists of crypto algorithms
> > that are selected by the IPsec kconfig options, and adds CRYPTO_SEQIV
On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote:
> The kzfree() function is normally used to clear some sensitive
> information, like encryption keys, in the buffer before freeing it back
> to the pool. Memset() is currently used for the buffer clearing. However,
> it is entirely possib
From: Eric Biggers
The crypto algorithms selected by the ESP and AH kconfig options are
out-of-date with the guidance of RFC 8221, which lists the legacy
algorithms MD5 and DES as "MUST NOT" be implemented, and some more
modern algorithms like AES-GCM and HMAC-SHA256 as "MUST&
d commit messages (added Acked-by tags, fixed a bad Fixes tag,
added some more explanation to patch 3).
Eric Biggers (3):
esp, ah: consolidate the crypto algorithm selections
esp: select CRYPTO_SEQIV
esp, ah: modernize the crypto algorithm selections
net/ipv4/Kconfig | 34 ++
From: Eric Biggers
Instead of duplicating the algorithm selections between INET_AH and
INET6_AH and between INET_ESP and INET6_ESP, create new tristates
XFRM_AH and XFRM_ESP that do the algorithm selections, and make these be
selected by the corresponding INET* options.
Suggested-by: Herbert Xu
From: Eric Biggers
Commit f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV") made
CRYPTO_CTR stop selecting CRYPTO_SEQIV. This breaks IPsec for most
users since GCM and several other encryption algorithms require "seqiv"
-- and RFC 8221 lists AES-GCM as "MU
From: Eric Biggers
The crypto algorithms selected by the ESP and AH kconfig options are
out-of-date with the guidance of RFC 8221, which lists the legacy
algorithms MD5 and DES as "MUST NOT" be implemented, and some more
modern algorithms like AES-GCM and HMAC-SHA256 as "MUST&
From: Eric Biggers
Instead of duplicating the algorithm selections between INET_AH and
INET6_AH and between INET_ESP and INET6_ESP, create new tristates
XFRM_AH and XFRM_ESP that do the algorithm selections, and make these be
selected by the corresponding INET* options.
Suggested-by: Herbert Xu
From: Eric Biggers
Commit f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV") made
CRYPTO_CTR stop selecting CRYPTO_SEQIV. This breaks IPsec for most
users since GCM and several other encryption algorithms require "seqiv"
-- and RFC 8221 lists AES-GCM as "MU
...@kernel.org/T/#u
Changed v3 => v4:
- Don't say that AH is "NOT RECOMMENDED" by RFC 8221.
- Updated commit messages (added Acked-by tags, fixed a bad Fixes tag,
added some more explanation to patch 3).
Eric Biggers (3):
esp, ah: consolidate the crypto algorithm select
On Wed, Jun 10, 2020 at 11:03:55AM +0200, Tobias Brunner wrote:
> Hi Eric,
>
> > + Note that RFC 8221 considers AH itself to be "NOT RECOMMENDED". It is
> > + better to use ESP only, using an AEAD cipher such as AES-GCM.
>
> What's NOT RECOMMENDED according to the RFC is the combination
From: Eric Biggers
The crypto algorithms selected by the ESP and AH kconfig options are
out-of-date with the guidance of RFC 8221, which lists the legacy
algorithms MD5 and DES as "MUST NOT" be implemented, and some more
modern algorithms like AES-GCM and HMAC-SHA256 as "MUST&
From: Eric Biggers
Commit f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV") made
CRYPTO_CTR stop selecting CRYPTO_SEQIV. This breaks IPsec for most
users since GCM and several other encryption algorithms require "seqiv"
-- and RFC 8221 lists AES-GCM as "MU
From: Eric Biggers
Instead of duplicating the algorithm selections between INET_AH and
INET6_AH and between INET_ESP and INET6_ESP, create new tristates
XFRM_AH and XFRM_ESP that do the algorithm selections, and make these be
selected by the corresponding INET* options.
Suggested-by: Herbert Xu
...@kernel.org/T/#u
Eric Biggers (3):
esp, ah: consolidate the crypto algorithm selections
esp: select CRYPTO_SEQIV
esp, ah: modernize the crypto algorithm selections
net/ipv4/Kconfig | 37 +
net/ipv6/Kconfig | 37 +
net/xfrm
On Fri, Jun 05, 2020 at 10:39:31AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> CRYPTO_CTR no longer selects CRYPTO_SEQIV, which breaks IPsec for users
> who need any of the algorithms that use seqiv. These users now would
> need to explicitly enable CRYPTO_SEQIV.
>
&g
From: Eric Biggers
CRYPTO_CTR no longer selects CRYPTO_SEQIV, which breaks IPsec for users
who need any of the algorithms that use seqiv. These users now would
need to explicitly enable CRYPTO_SEQIV.
There doesn't seem to be a clear rule on what algorithms the IPsec
options (INET_ES
On Fri, Jun 05, 2020 at 05:00:37AM -0700, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)"
>
> The XArray interface is easier for this driver to use. Also fixes a
> bug reported by the improper use of GFP_ATOMIC.
>
> Signed-off-by: Matthew Wilcox (Oracle)
This fixes https://lkml.kernel
On Fri, Jun 05, 2020 at 04:29:22AM -0700, Matthew Wilcox wrote:
> On Thu, Jun 04, 2020 at 08:55:55PM -0700, Eric Biggers wrote:
> > Possibly a bug in lib/radix-tree.c? this_cpu_ptr() in
> > radix_tree_node_alloc()
> > can be reached without a prior preempt_disable().
On Fri, Jun 05, 2020 at 10:29:56AM +1000, Herbert Xu wrote:
> On Fri, Jun 05, 2020 at 10:28:58AM +1000, Herbert Xu wrote:
> >
> > Hmm, the selection list doesn't include CTR so just adding SEQIV
> > per se makes no sense. I'm not certain that we really want to
> > include every algorithm under the
On Wed, May 20, 2020 at 07:56:41AM +0200, Greg KH wrote:
> On Tue, May 19, 2020 at 09:53:16PM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:d00f26b6 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> > git tree: net-next
> > console
On Thu, Jun 04, 2020 at 07:42:18AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:065fcfd4 selftests: net: ip_defrag: ignore EPERM
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15c3e51610
> kernel config: ht
[+Cc Matthew Wilcox]
Possibly a bug in lib/radix-tree.c? this_cpu_ptr() in radix_tree_node_alloc()
can be reached without a prior preempt_disable(). Or is the caller of
idr_alloc() doing something wrong?
On Thu, Jun 04, 2020 at 07:02:18PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the foll
+Cc linux-crypto. crypto_free_shash() is being called in atomic context;
perhaps that should be allowed? kfree() can be called in atomic context.
On Thu, Jun 04, 2020 at 05:33:19PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:39884604 mptcp: fix NU
From: Eric Biggers
Since CRYPTO_CTR no longer selects CRYPTO_SEQIV, it should be selected
by INET_ESP and INET6_ESP -- similar to CRYPTO_ECHAINIV.
Fixes: f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV")
Cc: Corentin Labbe
Cc: Greg Kroah-Hartman
Cc: Herbert Xu
Cc: Steffe
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:
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
[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
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
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
[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
[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
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.
> > >
> &
[+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
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 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, 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 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 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 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 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 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 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 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
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
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-
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 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 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
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 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:
>
>
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
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:
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
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
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_generic.c; it still happens on Linus' tree and it's
> > easily
>
[+ppp list and maintainer]
On Wed, Feb 28, 2018 at 08:59:02AM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> f3afe530d644488a074291da04a69a296ab63046 (Tue Feb 27 22:02:39 2018 +)
> Merge branch 'fixes-v4.16-rc4' of
> git://git.kernel.org/pub/scm/linux/ke
On Fri, Feb 09, 2018 at 12:00:01PM -0800, syzbot wrote:
> syzbot has found reproducer for the following crash on net-next commit
> 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +)
> Merge tag 'usercopy-v4.16-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
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
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
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, 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 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 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 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 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 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 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 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 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
[+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 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
>
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 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
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 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,
1 - 100 of 190 matches
Mail list logo
