On Thu, May 09, 2019 at 04:22:56PM +0200, 'Dmitry Vyukov' via syzkaller wrote:
> > > > > Can the KVM maintainers take a look at this? This doesn't have
> > > > > anything to do
> > > > > with my commit that syzbot bisected it to.
> > > > >
> > > > > +Dmitry, statistics lession: if a crash occurs
On Wed, May 08, 2019 at 06:58:28PM +0200, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> From: Dmitry Vyukov
> Date: Wed, May 8, 2019 at 1:25 PM
> To: Eric Biggers
> Cc: syzbot, KVM list, , David Miller, Artem
> Bityutskiy, , Josh Poimboeuf, LKML,
> , Andy Lutomirski, I
-
> Clean up fscrypt's dcache revalidation support, and other
> miscellaneous cleanups.
>
> ----
> Eric Biggers (10):
> fscrypt: drop inode argument from fscrypt_get_ctx()
> fscrypt: remove WAR
x=1266a588a0
>
> The bug was bisected to:
>
> commit 252153ba518ac0bcde6b7152c63380d4415bfe5d
> Author: Eric Biggers
> Date: Wed Nov 29 20:43:17 2017 +
>
> ubifs: switch to fscrypt_prepare_setattr()
>
> bisection log: https://syzkaller.ap
On Fri, Apr 26, 2019 at 10:01:02AM -0400, Theodore Ts'o wrote:
> On Fri, Apr 26, 2019 at 11:33:09AM +, Reshetova, Elena wrote:
> > Adding Eric and Herbert to continue discussion for the chacha part.
> > So, as a short summary I am trying to find out a fast (fast enough to be
> > used per sysc
Hi Dmitry,
On Fri, Apr 12, 2019 at 01:04:27PM +0200, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Thu, Apr 11, 2019 at 4:23 AM Al Viro wrote:
> >
> > On Thu, Apr 11, 2019 at 08:50:17AM +0800, Ian Kent wrote:
> > > On Wed, 2019-04-10 at 14:41 +0200, Dmitry Vyukov wrote:
> > > > On Wed, Apr 10,
On Mon, Apr 01, 2019 at 11:01:13AM +0200, Johannes Thumshirn wrote:
> Over the last 20 years, the Linux kernel has accumulated hundreds if not
> thousands of security vulnerabilities.
>
> One common pattern in most of these security related reports is processes
> called "syzkaller", "trinity" or "
Hi Richard,
On Thu, Mar 14, 2019 at 06:15:59PM +0100, Richard Weinberger wrote:
> Usually fscrypt allows limited access to encrypted files even
> if no key is available.
> Encrypted filenames are shown and based on this names users
> can unlink and move files.
Actually, fscrypt doesn't allow movi
On Wed, Mar 13, 2019 at 07:43:38AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> > Also, humans can sometimes find more simpler C reproducers from syzbot
> > provided
> > reproducers. It would be nice if syzbot can accept and use a user defined C
> > reproducer for testing.
>
> It would be
On Wed, Mar 13, 2019 at 03:29:43PM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 15:13 -0700, Eric Biggers wrote:
> > On Wed, Mar 13, 2019 at 02:04:29PM -0700, James Bottomley wrote:
> > > On Wed, 2019-03-13 at 13:25 -0700, Eric Biggers wrote:
> > > > On W
On Wed, Mar 13, 2019 at 09:33:10PM +0100, Richard Weinberger wrote:
> Am Mittwoch, 13. März 2019, 15:26:54 CET schrieb Amir Goldstein:
> > IMO, the best thing for UBIFS to do would be to modify fscrypt to support
> > opting out of the revalidate behavior, IWO, sanitize your hack to an API.
>
> Giv
On Wed, Mar 13, 2019 at 02:04:29PM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 13:25 -0700, Eric Biggers wrote:
> > On Wed, Mar 13, 2019 at 01:06:06PM -0700, James Bottomley wrote:
> > > On Wed, 2019-03-13 at 12:57 -0700, Eric Biggers wrote:
> [...]
> > >
On Wed, Mar 13, 2019 at 01:06:06PM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 12:57 -0700, Eric Biggers wrote:
> > On Wed, Mar 13, 2019 at 12:17:52PM -0700, James Bottomley wrote:
> > > On Wed, 2019-03-13 at 14:58 -0400, Theodore Ts'o wrote:
> > > >
On Wed, Mar 13, 2019 at 12:17:52PM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 14:58 -0400, Theodore Ts'o wrote:
> > On Wed, Mar 13, 2019 at 10:45:04AM -0700, James Bottomley wrote:
> > > > If they can't break root, then the OS's user-id based access
> > > > control checks (or SELinux c
On Wed, Mar 13, 2019 at 07:19:46PM +, Al Viro wrote:
> On Wed, Mar 13, 2019 at 09:44:33AM -0700, Eric Biggers wrote:
>
> > > Just to make sure - you do realize that ban on multiple dentries refering
> > > to the same directory inode is *NOT* conditional upon those den
On Wed, Mar 13, 2019 at 09:24:21AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Tue, Mar 12, 2019 at 11:50 PM Eric Biggers wrote:
> >
> > On Tue, Mar 12, 2019 at 09:33:44AM +0100, 'Dmitry Vyukov' via
> > syzkaller-bugs wrote:
> >
On Wed, Mar 13, 2019 at 04:06:16PM +, Al Viro wrote:
> On Wed, Mar 13, 2019 at 11:16:33AM -0400, Theodore Ts'o wrote:
> > Actually, the original use was for ChromeOS, but the primary
> > assumption is that keying is per user (or profile), and that users are
> > mutually distrustful. So when Al
On Wed, Mar 13, 2019 at 04:11:48PM +, Al Viro wrote:
> On Wed, Mar 13, 2019 at 08:01:27AM -0700, Eric Biggers wrote:
>
> > What do you think about this?
>
> That fscrypt might have some very deep flaws. I'll need to RTFS and
> review its model, but what I'v
Hi James,
On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 11:16 -0400, Theodore Ts'o wrote:
> > So before we talk about how to make things work from a technical
> > perspective, we should consider what the use case happens to be, and
> > what are the securi
On Wed, Mar 13, 2019 at 04:26:54PM +0200, Amir Goldstein wrote:
> On Wed, Mar 13, 2019 at 3:34 PM Richard Weinberger wrote:
> >
> > Am Mittwoch, 13. März 2019, 14:24:47 CET schrieb Miklos Szeredi:
> > > > The use case is that you can delete these files if the DAC/MAC
> > > > permissions allow it.
Hi Miklos,
On Wed, Mar 13, 2019 at 02:24:47PM +0100, Miklos Szeredi wrote:
> On Wed, Mar 13, 2019 at 2:00 PM Richard Weinberger wrote:
> >
> > Am Mittwoch, 13. März 2019, 13:58:11 CET schrieb Miklos Szeredi:
> > > On Wed, Mar 13, 2019 at 1:47 PM Richard Weinberger wrote:
> > > >
> > > > Am Mittw
On Tue, Mar 12, 2019 at 09:33:44AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Tue, Mar 12, 2019 at 7:25 AM Andrew Morton
> wrote:
> >
> > On Tue, 12 Mar 2019 07:08:38 +0100 Dmitry Vyukov wrote:
> >
> > > On Tue, Mar 12, 2019 at 12:37 AM Andrew Morton
> > > wrote:
> > > >
> > > > On
Hi Dmitry,
On Tue, Mar 12, 2019 at 09:21:09AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Tue, Mar 12, 2019 at 7:43 AM Eric Biggers wrote:
> >
> > On Mon, Mar 11, 2019 at 11:25:41PM -0700, Andrew Morton wrote:
> > > On Tue, 12 Mar 2019 07:08:38
On Mon, Mar 11, 2019 at 11:25:41PM -0700, Andrew Morton wrote:
> On Tue, 12 Mar 2019 07:08:38 +0100 Dmitry Vyukov wrote:
>
> > On Tue, Mar 12, 2019 at 12:37 AM Andrew Morton
> > wrote:
> > >
> > > On Mon, 11 Mar 2019 06:08:01 -0700 syzbot
> > > wrote:
> > >
> > > > syzbot has bisected this bug
129ca2d2a83f44551e73a408fa5e75a7b5169abb:
MAINTAINERS: add Eric Biggers as an fscrypt maintainer (2019-02-20 15:33:28
-0800)
fscrypt updates for v5.1
First: Ted, Jaegeuk, and I have decided to add me as a co-maintainer for
fscrypt, and we're now us
On Fri, Mar 01, 2019 at 11:05:05PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:42fd8df9d1d9 Add linux-next specific files for 20190228
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16c3cd5cc0
> kernel co
On Thu, Feb 28, 2019 at 10:31:53AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Thu, Feb 28, 2019 at 8:59 AM Eric Biggers wrote:
> >
> > On Thu, Feb 28, 2019 at 07:53:09AM +0100, 'Dmitry Vyukov' via
> > syzkaller-bugs wrote:
> > > O
On Thu, Feb 28, 2019 at 11:36:21AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Thu, Feb 28, 2019 at 11:32 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:42fd8df9d1d9 Add linux-next specific files for 20190228
> > git tree: li
t.
>
> This is now happening because of ff9fb72bc077 ("debugfs: return error
> values, not NULL"). syzbot has found a way to trigger multiple debugfs
> files attempting to be created, which fails, and then the error code
> gets passed to dentry_path_raw() which obviou
On Thu, Feb 28, 2019 at 07:53:09AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Wed, Feb 27, 2019 at 9:53 PM Eric Biggers wrote:
> >
> > On Tue, Feb 26, 2019 at 10:21:30AM -0800, Eric Biggers wrote:
> > > On Wed, Feb 13, 2019 at 12:23:31PM -0800, Andre
On Wed, Feb 27, 2019 at 06:13:19AM -0700, Jens Axboe wrote:
> On 2/26/19 11:11 PM, Eric Biggers wrote:
> > On Tue, Feb 26, 2019 at 10:02:04PM -0800, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD com
On Tue, Feb 26, 2019 at 10:21:30AM -0800, Eric Biggers wrote:
> On Wed, Feb 13, 2019 at 12:23:31PM -0800, Andrew Morton wrote:
> > On Wed, 13 Feb 2019 09:56:04 -0800 syzbot
> > wrote:
> >
> > > Hello,
> > >
> > > syzbot found the following cra
Reviving this old thread because it wasn't fully fixed after all...
On Tue, May 15, 2018 at 07:33:48AM +0200, Dmitry Vyukov wrote:
> On Mon, May 14, 2018 at 7:25 PM, Eric Biggers wrote:
> > On Mon, May 14, 2018 at 07:14:41AM +0200, Dmitry Vyukov wrote:
> >> On Mon, May 14
On Tue, Feb 26, 2019 at 10:02:04PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:8e7f81e2ebc4 Add linux-next specific files for 20190226
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10381714c0
> 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, 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 Tue, Aug 14, 2018 at 12:50:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:1c2f2531cf8b Add linux-next specific files for 20180809
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16016cf840
> kernel co
From: Eric Biggers
If drm_gem_handle_create() fails in vkms_gem_create(), then the
vkms_gem_object is freed twice: once when the reference is dropped by
drm_gem_object_put_unlocked(), and again by the extra calls to
drm_gem_object_release() and kfree().
Fix it by skipping the second release and
From: Eric Biggers
If drm_gem_handle_create() fails in vgem_gem_create(), then the
drm_vgem_gem_object is freed twice: once when the reference is dropped
by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
This was hit by syzkaller using fault injection.
Fix it by skipping the
On Tue, Feb 26, 2019 at 09:01:29PM +, Chris Wilson wrote:
> Quoting Eric Biggers (2019-02-26 20:47:26)
> > From: Eric Biggers
> >
> > If drm_gem_handle_create() fails in vgem_gem_create(), then the
> > drm_vgem_gem_object is freed twice: once when the
From: Eric Biggers
If drm_gem_handle_create() fails in vgem_gem_create(), then the
drm_vgem_gem_object is freed twice: once when the reference is dropped
by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().
This was hit by syzkaller using fault injection.
Fix it by skipping the
On Wed, Feb 20, 2019 at 08:14:03PM -0800, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:2137397c92ae Merge tag 'sound-5.0' of git://git.kernel.org..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1270bf78c0
On Wed, Feb 13, 2019 at 12:23:31PM -0800, Andrew Morton wrote:
> On Wed, 13 Feb 2019 09:56:04 -0800 syzbot
> wrote:
>
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:c4f3ef3eb53f Add linux-next specific files for 20190213
> > git tree: linux-next
> > conso
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 Wed, Feb 20, 2019 at 05:03:38PM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Mon, Oct 8, 2018 at 12:06 PM Ard Biesheuvel
> wrote:
> >
> > (add the TLS maintainers)
> >
> > On 6 October 2018 at 15:04, syzbot
> > wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> >
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-
On Thu, Feb 07, 2019 at 03:35:09PM -0800, Eric Biggers wrote:
> On Mon, Jan 14, 2019 at 07:37:16PM -0800, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Align the payload of "user" and "logon" keys so that users of the
> > keyrings service ca
On Thu, Feb 07, 2019 at 03:35:29PM -0800, Eric Biggers wrote:
> On Thu, Jan 10, 2019 at 12:27:46PM -0800, Eric Biggers wrote:
> > On Wed, Nov 28, 2018 at 03:19:41PM -0800, Eric Biggers wrote:
> > > On Fri, Nov 02, 2018 at 06:58:54PM -0700, Eric Biggers wrote:
> >
[+Cc linux-fscrypt]
Hi David,
On Fri, Feb 15, 2019 at 04:10:45PM +, David Howells wrote:
> Allow a container manager to attach keyrings to a container such that the
> keys contained therein are searched by request_key() in addition to a
> process's normal keyrings. This allows the manager to
On Fri, Feb 15, 2019 at 01:24:42PM +0800, Herbert Xu wrote:
> On Wed, Feb 13, 2019 at 10:51:36AM -0800, Eric Biggers wrote:
> >
> > You are claiming you need DES-ECB, 3DES-ECB, *and* ARC4 for that?
> >
> > Which one is it actually, if any?
>
> Since these are
On Wed, Feb 13, 2019 at 06:45:16PM +, Horia Geanta wrote:
> On 2/9/2019 11:52 PM, Eric Biggers wrote:
> > Do you have an actual use case for adding more DES, 3DES, and ARC4
> > implementations, or are you simply adding them because the hardware happens
> > to
> &
From: Eric Biggers
If the sysctl 'kernel.keys.maxkeys' is set to some number n, then
actually users can only add up to 'n - 1' keys. Likewise for
'kernel.keys.maxbytes' and the root_* versions of these sysctls. But
these sysctls are apparently supposed to be *max
Hi Iuliana,
On Fri, Feb 08, 2019 at 03:50:06PM +0200, Iuliana Prodan wrote:
> This patch set adds ecb mode support for aes, des, 3des and arc4 ciphers.
> skcipher implementation is reused, making sure to handle the no IV case.
>
> While here:
> -fix a DMA API issue where initial src/dst_nents are
On Thu, Jan 10, 2019 at 12:27:46PM -0800, Eric Biggers wrote:
> On Wed, Nov 28, 2018 at 03:19:41PM -0800, Eric Biggers wrote:
> > On Fri, Nov 02, 2018 at 06:58:54PM -0700, Eric Biggers wrote:
> > > From: Eric Biggers
> > >
> > > syzbot hit the &#
On Mon, Jan 14, 2019 at 07:37:16PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> Align the payload of "user" and "logon" keys so that users of the
> keyrings service can access it as a struct that requires more than
> 2-byte alignment. fscrypt currently
From: Eric Biggers
The generic MORUS implementations all fail the improved AEAD tests
because they produce the wrong result with some data layouts. The issue
is that they assume that if the skcipher_walk API gives 'nbytes' not
aligned to the walksize (a.k.a. walk.stride), then it is
From: Eric Biggers
The generic AEGIS implementations all fail the improved AEAD tests
because they produce the wrong result with some data layouts. The issue
is that they assume that if the skcipher_walk API gives 'nbytes' not
aligned to the walksize (a.k.a. walk.stride), then it is
From: Eric Biggers
The arm64 NEON bit-sliced implementation of AES-CTR fails the improved
skcipher tests because it sometimes produces the wrong ciphertext. The
bug is that the final keystream block isn't returned from the assembly
code when the number of non-final blocks is zero. Thi
From: Eric Biggers
Check that algorithms do not change the aead_request structure, as users
may rely on submitting the request again (e.g. after copying new data
into the same source buffer) without reinitializing everything.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 44
From: Eric Biggers
Check that algorithms do not change the skcipher_request structure, as
users may rely on submitting the request again (e.g. after copying new
data into the same source buffer) without reinitializing everything.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 41
From: Eric Biggers
Hash algorithms with an alignmask set, e.g. "xcbc(aes-aesni)" and
"michael_mic", fail the improved hash tests because they sometimes
produce the wrong digest. The bug is that in the case where a
scatterlist element crosses pages, not all the data is act
From: Eric Biggers
Add functions that generate a random testvec_config, in preparation for
using it for randomized fuzz tests.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 117 +++
1 file changed, 117 insertions(+)
diff --git a/crypto
From: Eric Biggers
Crypto algorithms must produce the same output for the same input
regardless of data layout, i.e. how the src and dst scatterlists are
divided into chunks and how each chunk is aligned. Request flags such
as CRYPTO_TFM_REQ_MAY_SLEEP must not affect the result either.
However
From: Eric Biggers
To achieve more comprehensive crypto test coverage, I'd like to add fuzz
tests that use random data layouts and request flags.
To be most effective these tests should be part of testmgr, so they
automatically run on every algorithm registered with the crypto API.
Ho
From: Eric Biggers
Convert alg_test_skcipher() to use the new test framework, adding a list
of testvec_configs to test by default. When the extra self-tests are
enabled, randomly generated testvec_configs are tested as well.
This improves skcipher test coverage mainly because now all
EGIS and MORUS fixes.
- A few very minor cleanups to the test code.
Eric Biggers (15):
crypto: aegis - fix handling chunked inputs
crypto: morus - fix handling chunked inputs
crypto: x86/aegis - fix handling chunked inputs and MAY_SLEEP
crypto: x86/morus - fix handling chunked inputs and MAY_S
From: Eric Biggers
gcmaes_crypt_by_sg() dereferences the NULL pointer returned by
scatterwalk_ffwd() when encrypting an empty plaintext and the source
scatterlist ends immediately after the associated data.
Fix it by only fast-forwarding to the src/dst data scatterlists if the
data length is
From: Eric Biggers
The x86 MORUS implementations all fail the improved AEAD tests because
they produce the wrong result with some data layouts. The issue is that
they assume that if the skcipher_walk API gives 'nbytes' not aligned to
the walksize (a.k.a. walk.stride), then it is the
From: Eric Biggers
Convert alg_test_aead() to use the new test framework, using the same
list of testvec_configs that skcipher testing uses.
This significantly improves AEAD test coverage mainly because previously
there was only very limited test coverage of the possible data layouts.
Now the
From: Eric Biggers
The x86 AEGIS implementations all fail the improved AEAD tests because
they produce the wrong result with some data layouts. The issue is that
they assume that if the skcipher_walk API gives 'nbytes' not aligned to
the walksize (a.k.a. walk.stride), then it is the
From: Eric Biggers
Convert alg_test_hash() to use the new test framework, adding a list of
testvec_configs to test by default. When the extra self-tests are
enabled, randomly generated testvec_configs are tested as well.
This improves hash test coverage mainly because now all algorithms have
a
On Fri, Feb 01, 2019 at 01:31:46PM +0800, Herbert Xu wrote:
> On Wed, Jan 23, 2019 at 02:49:20PM -0800, Eric Biggers wrote:
> >
> > diff --git a/crypto/Kconfig b/crypto/Kconfig
> > index 86960aa53e0f..cbeba16fd8c1 100644
> > --- a/crypto/Kconfig
> > +++ b/cry
On Thu, Jan 31, 2019 at 10:05:17AM +0100, Ondrej Mosnacek wrote:
> Hi Eric,
>
> On Wed, Jan 23, 2019 at 11:52 PM Eric Biggers wrote:
> > From: Eric Biggers
> >
> > The generic MORUS implementations all fail the improved AEAD tests
> > because they produce the wr
On Thu, Jan 24, 2019 at 12:03:37AM -0500, Theodore Y. Ts'o wrote:
> On Thu, Jan 10, 2019 at 05:01:17PM -0800, Eric Biggers wrote:
> >
> > Indeed, Chandan Rajendra sent out a new version of the patch which fixes the
> > problem (by removing the 'select BLOCK'
On Thu, Jan 24, 2019 at 05:23:59PM +0800, Herbert Xu wrote:
> On Thu, Jan 24, 2019 at 09:50:35AM +0100, Ard Biesheuvel wrote:
> >
> > Thanks for yet another round of cleanup
> >
> > I'll look into these, but I'd like to clarify one thing first.
> >
> > IIUC, you are trying to deal with the case w
On Wed, Jan 23, 2019 at 02:49:11PM -0800, Eric Biggers wrote:
> Hello,
>
> Crypto algorithms must produce the same output for the same input
> regardless of data layout, i.e. how the src and dst scatterlists are
> divided into chunks and how each chunk is aligned. Request
From: Eric Biggers
Hash algorithms with an alignmask set, e.g. "xcbc(aes-aesni)" and
"michael_mic", fail the improved hash tests because they sometimes
produce the wrong digest. The bug is that in the case where a
scatterlist element crosses pages, not all the data is act
From: Eric Biggers
The arm64 NEON bit-sliced implementation of AES-CTR fails the improved
skcipher tests because it sometimes produces the wrong ciphertext. The
bug is that the final keystream block isn't returned from the assembly
code when the number of non-final blocks is zero. Thi
From: Eric Biggers
gcmaes_crypt_by_sg() dereferences the NULL pointer returned by
scatterwalk_ffwd() when encrypting an empty plaintext and the source
scatterlist ends immediately after the associated data.
Fix it by only fast-forwarding to the src/dst data scatterlists if the
data length is
From: Eric Biggers
To achieve more comprehensive crypto test coverage, I'd like to add fuzz
tests that use random data layouts and request flags.
To be most effective these tests should be part of testmgr, so they
automatically run on every algorithm registered with the crypto API.
Ho
From: Eric Biggers
Add functions that generate a random testvec_config, in preparation for
using it for randomized fuzz tests.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 117 +++
1 file changed, 117 insertions(+)
diff --git a/crypto
From: Eric Biggers
The x86 AEGIS implementations all fail the improved AEAD tests because
they produce the wrong result with some data layouts. Also, when the
MAY_SLEEP flag is given, they can sleep in the skcipher_walk_*()
functions while preemption is disabled by kernel_fpu_begin().
Fix
From: Eric Biggers
Crypto algorithms must produce the same output for the same input
regardless of data layout, i.e. how the src and dst scatterlists are
divided into chunks and how each chunk is aligned. Request flags such
as CRYPTO_TFM_REQ_MAY_SLEEP must not affect the result either.
However
From: Eric Biggers
Check that algorithms do not change the aead_request structure, as users
may rely on submitting the request again (e.g. after copying new data
into the same source buffer) without reinitializing everything.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 44
From: Eric Biggers
Convert alg_test_aead() to use the new test framework, using the same
list of testvec_configs that skcipher testing uses.
This significantly improves AEAD test coverage mainly because previously
there was only very limited test coverage of the possible data layouts.
Now the
From: Eric Biggers
Check that algorithms do not change the skcipher_request structure, as
users may rely on submitting the request again (e.g. after copying new
data into the same source buffer) without reinitializing everything.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 41
From: Eric Biggers
Convert alg_test_hash() to use the new test framework, adding a list of
testvec_configs to test by default. When the extra self-tests are
enabled, randomly generated testvec_configs are tested as well.
This improves hash test coverage mainly because now all algorithms have
a
From: Eric Biggers
The generic AEGIS implementations all fail the improved AEAD tests
because they produce the wrong result with some data layouts. Fix them.
Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD implementations")
Cc: # v4.18+
Cc: Ondrej Mosnacek
Signed-of
From: Eric Biggers
The x86 MORUS implementations all fail the improved AEAD tests because
they produce the wrong result with some data layouts. Also, when the
MAY_SLEEP flag is given, they can sleep in the skcipher_walk_*()
functions while preemption is disabled by kernel_fpu_begin().
Fix
From: Eric Biggers
Convert alg_test_skcipher() to use the new test framework, adding a list
of testvec_configs to test by default. When the extra self-tests are
enabled, randomly generated testvec_configs are tested as well.
This improves skcipher test coverage mainly because now all
es can also be found in git at
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
branch "testmgr-improvements".
(*) Except that many AEADs incorrectly change aead_request::base.tfm.
I've left fixing that for later patches.
Eric Biggers (15):
crypto: aegis - fix
From: Eric Biggers
The generic MORUS implementations all fail the improved AEAD tests
because they produce the wrong result with some data layouts. Fix them.
Fixes: 396be41f16fd ("crypto: morus - Add generic MORUS AEAD implementations")
Cc: # v4.18+
Cc: Ondrej Mosnacek
Signed-of
On Thu, Jan 17, 2019 at 02:48:02PM +0800, Xiongfeng Wang wrote:
> Use crypto template array registering API to simplify the code.
>
> Signed-off-by: Xiongfeng Wang
> ---
> crypto/ctr.c | 43 +++
> 1 file changed, 15 insertions(+), 28 deletions(-)
>
> diff
701 - 800 of 1326 matches
Mail list logo
