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
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
On Wed, Jul 15, 2020 at 07:45:27PM -0700, Suren Baghdasaryan wrote:
> syzbot report [1] describes a deadlock when write operation against an
> ashmem fd executed at the time when ashmem is shrinking its cache results
> in the following lock sequence:
>
> Possible unsafe locking scenario:
>
>
On Tue, Jul 14, 2020 at 11:32:52AM +0800, Hillf Danton wrote:
>
> Add FALLOC_FL_NOBLOCK and on the shmem side try to lock inode upon the
> new flag. And the overall upside is to keep the current gfp either in
> the khugepaged context or not.
>
> --- a/include/uapi/linux/falloc.h
> +++
[+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
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
ashmem is calling shmem_fallocate() during memory reclaim, which can deadlock on
inode_lock(). +Cc maintainers of drivers/staging/android/ashmem.c.
On Thu, Dec 26, 2019 at 01:25:09PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:46cf053e Linux
On Thu, Oct 17, 2019 at 10:02:07AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:bc88f85c kthread: make __kthread_queue_delayed_work static
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14e25608e0
> kernel
On Sun, Aug 18, 2019 at 09:22:01AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote:
> > Ted's observation was about maliciously-crafted filesystems, though, so
> > integrity-only features such as metadata checksums are ir
On Sun, Aug 18, 2019 at 08:58:12AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> > Note that of the mainstream file systems, ext4 and xfs don't guarantee
> > that it's safe to blindly take maliciously provided file systems, such
> > as those
[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 1 of them as possibly being a bug in the
[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 1 of them as possibly being a bug in the
[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
On Tue, Jan 16, 2018 at 06:20:37AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Tue, Jan 16, 2018 at 12:58 AM, syzbot
> wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 8418f88764046d0e8ca6a3c04a69a0e57189aa1e
> >
On Mon, May 20, 2019 at 07:18:06AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:72cf0b07 Merge tag 'sound-fix-5.2-rc1' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17c7d4bca0
>
Hi Krzysztof,
On Tue, Jul 17, 2018 at 06:05:35PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> Kernel defines same polynomial for CRC-32 in few places.
> This is unnecessary duplication of the same value. Also this might
> be error-prone for future code - every driver will define the
> polynomial
[+ashmem maintainers]
On Sun, Apr 29, 2018 at 10:00:03AM -0700, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> cdface5209349930ae1b51338763c8e029971b97 (Sun Apr 29 03:07:21 2018 +)
> Merge tag 'for_linus_stable' of
>
On Tue, Apr 03, 2018 at 08:02:02PM -0700, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> f2d285669aae656dfeafa0bf25e86bbbc5d22329 (Tue Apr 3 17:45:39 2018 +)
> Merge tag 'pm-4.17-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> syzbot
On Tue, Dec 26, 2017 at 02:20:01PM -0800, syzbot wrote:
> syzkaller has found reproducer for 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
On Fri, Dec 01, 2017 at 04:22:00PM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 3c1c4ddffb58b9e10b3365764fe59546130b3f32
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw
From: Eric Biggers <ebigg...@google.com>
If the kzalloc() in binder_get_thread() fails, binder_poll()
dereferences the resulting NULL pointer.
Fix it by returning POLLERR if the memory allocation failed.
This bug was found by syzkaller using fault injection.
Reported-by: syzbot &
On Mon, Dec 18, 2017 at 08:23:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> 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
On Tue, Dec 19, 2017 at 08:25:00AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> 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
On Tue, Dec 12, 2017 at 04:05:17PM -0800, Eric Biggers wrote:
> [+Cc binder maintainers and list]
> [-Cc lockdep maintainers, USB maintainers, and other random people]
>
> On Sat, Dec 02, 2017 at 08:08:01AM -0800, syzbot wrote:
> > BUG: KASAN: use-after-free in __lock_acq
[+Cc binder maintainers and list]
[-Cc lockdep maintainers, USB maintainers, and other random people]
On Sat, Dec 02, 2017 at 08:08:01AM -0800, syzbot wrote:
> BUG: KASAN: use-after-free in __lock_acquire+0x465e/0x47f0
> kernel/locking/lockdep.c:3378
> Read of size 8 at addr 8801cd8e13f0 by
26 matches
Mail list logo
