Cool, thanks!
Regards,
butt3rflyh4ck.
On Wed, Apr 21, 2021 at 2:27 AM Jaegeuk Kim wrote:
>
> Hi,
>
> On 04/20, Salvatore Bonaccorso wrote:
> > Hi,
> >
> > On Tue, Mar 23, 2021 at 02:43:29PM +0800, Chao Yu wrote:
> > > Hi butt3rflyh4ck,
> > >
> > > On 2021/3/23 13:48, butt3rflyh4ck wrote:
> > >
Hi,
On 04/20, Salvatore Bonaccorso wrote:
> Hi,
>
> On Tue, Mar 23, 2021 at 02:43:29PM +0800, Chao Yu wrote:
> > Hi butt3rflyh4ck,
> >
> > On 2021/3/23 13:48, butt3rflyh4ck wrote:
> > > Hi, I have tested the patch on 5.12.0-rc4+, it seems to fix the problem.
> >
> > Thanks for helping to test t
Hi,
On Tue, Mar 23, 2021 at 02:43:29PM +0800, Chao Yu wrote:
> Hi butt3rflyh4ck,
>
> On 2021/3/23 13:48, butt3rflyh4ck wrote:
> > Hi, I have tested the patch on 5.12.0-rc4+, it seems to fix the problem.
>
> Thanks for helping to test this patch.
Was this patch applied? I do not see it in mainli
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIV
On Thu, Apr 01, 2021, Vitaly Kuznetsov wrote:
> Sean Christopherson writes:
>
> > On Wed, Mar 31, 2021, Yang Li wrote:
> >> Using __set_bit() to set a bit in an integer is not a good idea, since
> >> the function expects an unsigned long as argument, which can be 64bit wide.
> >> Coverity reports
On Thu, Apr 01, 2021 at 01:20:05PM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 11:48:13 AM AEDT Jason Gunthorpe wrote:
> > On Thu, Apr 01, 2021 at 11:45:57AM +1100, Alistair Popple wrote:
> > > On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
> > > > On Thu, Apr 01, 2
Sean Christopherson writes:
> On Wed, Mar 31, 2021, Yang Li wrote:
>> Using __set_bit() to set a bit in an integer is not a good idea, since
>> the function expects an unsigned long as argument, which can be 64bit wide.
>> Coverity reports this problem as
>>
>> High:Out-of-bounds access(INCOMPAT
On Thursday, 1 April 2021 11:48:13 AM AEDT Jason Gunthorpe wrote:
> On Thu, Apr 01, 2021 at 11:45:57AM +1100, Alistair Popple wrote:
> > On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
> > > On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> > > > On Thursday, 1 Ap
On Thu, Apr 01, 2021 at 11:45:57AM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
> > On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> > > On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
> > > > On Wed, Mar 31, 2
On Thursday, 1 April 2021 12:46:04 AM AEDT Jason Gunthorpe wrote:
> On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> > On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
> > > On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
> > >
> > > > I guess th
On Wed, Mar 31, 2021, Yang Li wrote:
> Using __set_bit() to set a bit in an integer is not a good idea, since
> the function expects an unsigned long as argument, which can be 64bit wide.
> Coverity reports this problem as
>
> High:Out-of-bounds access(INCOMPATIBLE_CAST)
> CWE119: Out-of-bounds ac
On Thu, Apr 01, 2021 at 12:27:52AM +1100, Alistair Popple wrote:
> On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
> > On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
> >
> > > I guess that makes sense as the split could go either way at the
> > > moment but I sh
On Thursday, 1 April 2021 12:18:54 AM AEDT Jason Gunthorpe wrote:
> On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
>
> > I guess that makes sense as the split could go either way at the
> > moment but I should add a check to make sure this isn't used with
> > pinned pages anyway.
On Wed, Mar 31, 2021 at 11:59:28PM +1100, Alistair Popple wrote:
> I guess that makes sense as the split could go either way at the
> moment but I should add a check to make sure this isn't used with
> pinned pages anyway.
Is it possible to have a pinned page under one of these things? If I
pin i
On Wednesday, 31 March 2021 6:32:34 AM AEDT Jason Gunthorpe wrote:
> On Fri, Mar 26, 2021 at 11:08:02AM +1100, Alistair Popple wrote:
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 3a5705cfc891..33d11527ef77 100644
> > +++ b/mm/memory.c
> > @@ -781,6 +781,27 @@ copy_nonpresent_pte(struct mm_s
Using __set_bit() to set a bit in an integer is not a good idea, since
the function expects an unsigned long as argument, which can be 64bit wide.
Coverity reports this problem as
High:Out-of-bounds access(INCOMPATIBLE_CAST)
CWE119: Out-of-bounds access to a scalar
Pointer "&vcpu->arch.regs_avail"
On Fri, Mar 26, 2021 at 11:08:02AM +1100, Alistair Popple wrote:
> diff --git a/mm/memory.c b/mm/memory.c
> index 3a5705cfc891..33d11527ef77 100644
> +++ b/mm/memory.c
> @@ -781,6 +781,27 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct
> mm_struct *src_mm,
> p
- set_bit(MCE_OVERFLOW, (unsigned long *)&mcelog->flags);
+ mcelog->flags |= BIT(MCE_OVERFLOW);
set_bit() is an atomic operation because it might race with the code to
get and clear this bit:
do {
flags = mcelog->flags;
Using set_bit() to set a bit in an integer is not a good idea, since
the function expects an unsigned long as argument, which can be 64bit
wide.
Coverity reports this problem as
High:Out-of-bounds access(INCOMPATIBLE_CAST)
CWE119: Out-of-bounds access to a scalar
Pointer "&mcelog->flags" points to
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIV
Hi, I have tested the patch on 5.12.0-rc4+, it seems to fix the problem.
Regards,
butt3rflyh4ck.
On Mon, Mar 22, 2021 at 7:47 PM Chao Yu wrote:
>
> butt3rflyh4ck reported a bug found by
> syzkaller fuzzer with custom modifications in 5.12.0-rc3+ [1]:
>
> dump_stack+0xfa/0x151 lib/dump_stack.
Hi butt3rflyh4ck,
On 2021/3/23 13:48, butt3rflyh4ck wrote:
Hi, I have tested the patch on 5.12.0-rc4+, it seems to fix the problem.
Thanks for helping to test this patch.
Thanks,
Regards,
butt3rflyh4ck.
On Mon, Mar 22, 2021 at 7:47 PM Chao Yu wrote:
butt3rflyh4ck reported a bug fou
butt3rflyh4ck reported a bug found by
syzkaller fuzzer with custom modifications in 5.12.0-rc3+ [1]:
dump_stack+0xfa/0x151 lib/dump_stack.c:120
print_address_description.constprop.0.cold+0x82/0x32c mm/kasan/report.c:232
__kasan_report mm/kasan/report.c:399 [inline]
kasan_report.cold+0x7c/0xd8
On Monday, 15 March 2021 6:42:45 PM AEDT Christoph Hellwig wrote:
> > +Not all devices support atomic access to system memory. To support atomic
> > +operations to a shared virtual memory page such a device needs access to
that
> > +page which is exclusive of any userspace access from the CPU. The
> +Not all devices support atomic access to system memory. To support atomic
> +operations to a shared virtual memory page such a device needs access to that
> +page which is exclusive of any userspace access from the CPU. The
> +``make_device_exclusive_range()`` function can be used to make a memo
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIV
Hi Alistair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on s390/features]
[also build test ERROR on linus/master v5.12-rc2 next-20210309]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIV
On Tuesday, 9 March 2021 6:44:41 AM AEDT Ralph Campbell wrote:
>
> On 3/3/21 10:16 PM, Alistair Popple wrote:
> > Some devices require exclusive write access to shared virtual
> > memory (SVM) ranges to perform atomic operations on that memory. This
> > requires CPU page tables to be updated to de
: Borislav Petkov
CommitterDate: Mon, 08 Mar 2021 20:41:33 +01:00
x86/virtio: Have SEV guests enforce restricted virtio memory access
An SEV guest requires that virtio devices use the DMA API to allow the
hypervisor to successfully access guest memory as needed.
The VIRTIO_F_VERSION_1 and
On 3/3/21 10:16 PM, Alistair Popple wrote:
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this intro
: Borislav Petkov
CommitterDate: Mon, 08 Mar 2021 12:54:43 +01:00
x86/virtio: Have SEV guests enforce restricted virtio memory access
An SEV guest requires that virtio devices use the DMA API to allow the
hypervisor to successfully access guest memory as needed.
The VIRTIO_F_VERSION_1 and
From: Tom Lendacky
An SEV guest requires that virtio devices use the DMA API to allow the
hypervisor to successfully access guest memory as needed.
The VIRTIO_F_VERSION_1 and VIRTIO_F_ACCESS_PLATFORM features tell virtio
to use the DMA API. Add arch_has_restricted_virtio_memory_access() for
x86,
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIV
On Tuesday, 2 March 2021 11:41:52 PM AEDT Jason Gunthorpe wrote:
> > However try_to_protect() scans the PTEs again under the PTL so checking
the
> > mapping of interest actually gets replaced during the rmap walk seems like
a
> > reasonable solution. Thanks for the comments.
>
> It does seem c
On Tue, Mar 02, 2021 at 07:57:58PM +1100, Alistair Popple wrote:
> The intent was a driver could use HMM or some other mechanism to keep PTEs
> synchronised if required. However I just looked at patch 8 in the series
> again
> and it appears I got this wrong when converting from the old migrati
On Tuesday, 2 March 2021 11:05:59 AM AEDT Jason Gunthorpe wrote:
> On Fri, Feb 26, 2021 at 06:18:29PM +1100, Alistair Popple wrote:
>
> > +/**
> > + * make_device_exclusive_range() - Mark a range for exclusive use by a
device
> > + * @mm: mm_struct of assoicated target process
> > + * @start: sta
On Fri, Feb 26, 2021 at 06:18:29PM +1100, Alistair Popple wrote:
> +/**
> + * make_device_exclusive_range() - Mark a range for exclusive use by a device
> + * @mm: mm_struct of assoicated target process
> + * @start: start of the region to mark for exclusive device access
> + * @end: end address o
hn Hubbard ; Ralph
> Campbell ; jgli...@redhat.com; Jason Gunthorpe
> ; h...@infradead.org; dan...@ffwll.ch; Alistair Popple
>
> Subject: [PATCH v3 5/8] mm: Device exclusive memory access
>
> Some devices require exclusive write access to shared virtual memory (SVM)
> ranges to p
On Fri, Feb 26, 2021 at 06:18:29PM +1100, Alistair Popple wrote:
> Some devices require exclusive write access to shared virtual
> memory (SVM) ranges to perform atomic operations on that memory. This
> requires CPU page tables to be updated to deny access whilst atomic
> operations are occurring.
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIV
On Friday, 19 February 2021 8:47:41 PM AEDT Christoph Hellwig wrote:
> > page = migration_entry_to_page(swpent);
> > else if (is_device_private_entry(swpent))
> > page = device_private_entry_to_page(swpent);
> > + else if (is_device_excl
On Fri, Feb 19, 2021 at 09:47:41AM +, Christoph Hellwig wrote:
> > diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> > index 866a0fa104c4..5d28ff6d4d80 100644
> > +++ b/include/linux/hmm.h
> > @@ -109,6 +109,10 @@ struct hmm_range {
> > */
> > int hmm_range_fault(struct hmm_range *ra
> page = migration_entry_to_page(swpent);
> else if (is_device_private_entry(swpent))
> page = device_private_entry_to_page(swpent);
> + else if (is_device_exclusive_entry(swpent))
> + page = device_exclusive_
Hi Alistair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kselftest/next]
[also build test ERROR on linus/master v5.11 next-20210218]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Apologies for the noise, looks like I don't have a CONFIG_DEVICE_PRIVATE=n
build in my tests and missed creating definitions for the new static inline
functions for that configuration.
I'll wait for some feedback on the overall approach and fix this in a v3.
- Alistair
On Friday, 19 February
Hi Alistair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kselftest/next]
[also build test ERROR on linus/master v5.11 next-20210218]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIV
84548b03ddcbbaf...@syzkaller.appspotmail.com
==
BUG: KASAN: wild-memory-access in instrument_atomic_read_write
include/linux/instrumented.h:101 [inline]
BUG: KASAN: wild-memory-access in atomic_fetch_sub_release
include/asm-generic/atomic-instrumented.h:2
Add an option to overlap the ranges of memory each vCPU accesses instead
of partitioning them. This option will increase the probability of
multiple vCPUs faulting on the same page at the same time, and causing
interesting races, if there are bugs in the page fault handler or
elsewhere in the kerne
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
tation of the same
problem we see in other crashes.
Let's make one canonical bug for this:
#syz dup: general protection fault in perf_misc_flags
> ======
> BUG: KASAN: user-memory-access in vdso_fault+0xc1/0x1b0
> arch/x86/ent
e issue, please add the following tag to the commit:
Reported-by: syzbot+fe2a9f19481e3bfed...@syzkaller.appspotmail.com
==
BUG: KASAN: user-memory-access in vdso_fault+0xc1/0x1b0
arch/x86/entry/vdso/vma.c:67
Read of size 8 at addr
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\
provides
> the arch_has_restricted_virtio_memory_access callback to advertise
> to VIRTIO common code when the architecture restricts memory access
> from the host.
>
> The common code can then fail the probe for any device where
> VIRTIO_F_ACCESS_PLATFORM is required, but not set.
>
>
VIRTIO common code when the architecture restricts memory access
from the host.
The common code can then fail the probe for any device where
VIRTIO_F_ACCESS_PLATFORM is required, but not set.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
Reviewed-by: Halil Pasic
---
drivers/virtio
provides
> the arch_has_restricted_virtio_memory_access callback to advertise
> to VIRTIO common code when the architecture restricts memory access
> from the host.
>
> The common code can then fail the probe for any device where
> VIRTIO_F_ACCESS_PLATFORM is required, but no
VIRTIO common code when the architecture restricts memory access
from the host.
The common code can then fail the probe for any device where
VIRTIO_F_ACCESS_PLATFORM is required, but not set.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
---
drivers/virtio/Kconfig| 6
On Mon, Aug 31, 2020 at 8:32 PM Andrew Morton wrote:
>
> On Mon, 31 Aug 2020 17:17:30 + albert.li...@gmail.com wrote:
>
> > The goal of this series is to improve testing of fault-tolerance in
> > usages of user memory access functions, by adding support for fault
&g
Hi Andrew,
On Mon, Aug 31, 2020 at 6:27 PM Akinobu Mita wrote:
>
> Andrew,
>
> Could you take a look at this series, and consider taking in -mm tree?
Please consider picking v3 patches that address Peter's comments instead.
>
> 2020年9月1日(火) 0:49 Alexander Potapenko :
> >
> > > This series looks
On Mon, 31 Aug 2020 17:17:30 + albert.li...@gmail.com wrote:
> The goal of this series is to improve testing of fault-tolerance in
> usages of user memory access functions, by adding support for fault
> injection.
Does anyone actually plan to use this feature, on an ongoing basis?
From: Albert van der Linde
The goal of this series is to improve testing of fault-tolerance in
usages of user memory access functions, by adding support for fault
injection.
The first patch adds failure injection capability for usercopy
functions. The second changes usercopy functions to use
Andrew,
Could you take a look at this series, and consider taking in -mm tree?
2020年9月1日(火) 0:49 Alexander Potapenko :
>
> > This series looks good to me.
>
> Great!
>
> Which tree do fault injection patches normally go to?
>
> > Reviewed-by: Akinobu Mita
>
> Reviewed-by: Alexander Potapenko
> This series looks good to me.
Great!
Which tree do fault injection patches normally go to?
> Reviewed-by: Akinobu Mita
Reviewed-by: Alexander Potapenko
2020年8月28日(金) 23:14 :
>
> From: Albert van der Linde
>
> The goal of this series is to improve testing of fault-tolerance in
> usages of user memory access functions, by adding support for fault
> injection.
>
> The first patch adds failure injection capability for u
VIRTIO common code when the architecture restricts memory access
from the host.
The common code can then fail the probe for any device where
VIRTIO_F_IOMMU_PLATFORM is required, but not set.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
---
drivers/virtio/Kconfig| 6
From: Albert van der Linde
The goal of this series is to improve testing of fault-tolerance in
usages of user memory access functions, by adding support for fault
injection.
The first patch adds failure injection capability for usercopy
functions. The second changes usercopy functions to use
ew Kconfig entry the architecture can select,
CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, when it provides
the arch_has_restricted_virtio_memory_access callback to advertise
s/advertise/advertise to/
OK
VIRTIO common code when the architecture restricts memory access
from the host.
&
itecture can select,
> CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS, when it provides
> the arch_has_restricted_virtio_memory_access callback to advertise
s/advertise/advertise to/
> VIRTIO common code when the architecture restricts memory access
> from the host.
"The common code can then
From: Albert van der Linde
The goal of this series is to improve testing of fault-tolerance in
usages of user memory access functions, by adding support for fault
injection.
The first patch adds failure injection capability for usercopy
functions. The second changes usercopy functions to use
restricts memory access
from the host.
Signed-off-by: Pierre Morel
---
drivers/virtio/Kconfig| 6 ++
drivers/virtio/virtio.c | 15 +++
include/linux/virtio_config.h | 9 +
3 files changed, 30 insertions(+)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio
it:
Reported-by: syzbot+64d60892aaa4d4c34...@syzkaller.appspotmail.com
BUG: KASAN: wild-memory-access in memcpy include/linux/string.h:406 [inline]
BUG: KASAN: wild-memory-access in copy_from_sockptr_offset
include/linux/sockptr.h:71 [inline]
BUG: KASAN: wild-memory-access in copy_from_sockptr include/
Hi,
The attached patch fixes an OOB memory access security bug. The bug is
already fixed in the upstream kernel due to the vulnerable code being
refactored in commit fe2d0020994c ("netfilter: nat: remove
l4proto->in_range") and commit d6c4c8ffb5e5 ("netfilter: nat: remove
l3proto
d22f3...@syzkaller.appspotmail.com
==
BUG: KASAN: user-memory-access in instrument_atomic_read
include/linux/instrumented.h:56 [inline]
BUG: KASAN: user-memory-access in atomic64_read
include/asm-generic/atomic-instrumented.h:837 [inline
ca998c125cfe13c...@syzkaller.appspotmail.com
==
BUG: KASAN: user-memory-access in memcpy include/linux/string.h:406 [inline]
BUG: KASAN: user-memory-access in scr_memcpyw include/linux/vt_buffer.h:49
[inline]
BUG: KASAN: user-m
rted-by: syzbot+961278f56598a876c...@syzkaller.appspotmail.com
==
BUG: KASAN: user-memory-access in vmcs12_guest_cr0
arch/x86/kvm/vmx/nested.c:3545 [inline]
BUG: KASAN: user-memory-access in sync_vmcs02_to_vmcs12+0x16fb/0x1a40
arch/x86/kvm/vm
- offs,
- (int)UBIFS_MAX_DATA_NODE_SZ);
- pr_err("\tprevent out-of-bounds memory access\n");
- pr_err("\ttruncated data node length %d\n",
safe_len);
- pr_err("\tcorrupted
rted-by: syzbot+c5c252a500b90d63e...@syzkaller.appspotmail.com
==
BUG: KASAN: user-memory-access in memcpy include/linux/string.h:381 [inline]
BUG: KASAN: user-memory-access in scr_memcpyw include/linux/vt_buffer.h:49
[inline]
BUG: KASAN: use
From: Mikulas Patocka
commit 0c8e9c2d668278652af028c3cc068c65f66342f4 upstream.
Commit 75d66ffb48efb30f2dd42f041ba8b39c5b2bd115 ("dm zoned: properly
handle backing device failure") triggers a coverity warning:
---
drivers/md/dm-zoned-target.c |2 --
1 file changed, 2 deletions(-)
--- a/dr
From: Chao Yu
[ Upstream commit a37d0862d17411edb67677a580a6f505ec2225f6 ]
As Pavel Machek reported:
"We normally use -EUCLEAN to signal filesystem corruption. Plus, it is
good idea to report it to the syslog and mark filesystem as "needing
fsck" if filesystem can do that."
Still we need impro
From: Chao Yu
[ Upstream commit a37d0862d17411edb67677a580a6f505ec2225f6 ]
As Pavel Machek reported:
"We normally use -EUCLEAN to signal filesystem corruption. Plus, it is
good idea to report it to the syslog and mark filesystem as "needing
fsck" if filesystem can do that."
Still we need impro
From: Mikulas Patocka
[ Upstream commit 0c8e9c2d668278652af028c3cc068c65f66342f4 ]
Commit 75d66ffb48efb30f2dd42f041ba8b39c5b2bd115 ("dm zoned: properly
handle backing device failure") triggers a coverity warning:
*** CID 1452808: Memory - illegal accesses (USE_AFTER_FREE)
/drivers/md/dm-zoned
From: Chao Yu
[ Upstream commit a37d0862d17411edb67677a580a6f505ec2225f6 ]
As Pavel Machek reported:
"We normally use -EUCLEAN to signal filesystem corruption. Plus, it is
good idea to report it to the syslog and mark filesystem as "needing
fsck" if filesystem can do that."
Still we need impro
From: Mikulas Patocka
[ Upstream commit 0c8e9c2d668278652af028c3cc068c65f66342f4 ]
Commit 75d66ffb48efb30f2dd42f041ba8b39c5b2bd115 ("dm zoned: properly
handle backing device failure") triggers a coverity warning:
*** CID 1452808: Memory - illegal accesses (USE_AFTER_FREE)
/drivers/md/dm-zoned
From: Chao Yu
[ Upstream commit a37d0862d17411edb67677a580a6f505ec2225f6 ]
As Pavel Machek reported:
"We normally use -EUCLEAN to signal filesystem corruption. Plus, it is
good idea to report it to the syslog and mark filesystem as "needing
fsck" if filesystem can do that."
Still we need impro
From: Mikulas Patocka
[ Upstream commit 0c8e9c2d668278652af028c3cc068c65f66342f4 ]
Commit 75d66ffb48efb30f2dd42f041ba8b39c5b2bd115 ("dm zoned: properly
handle backing device failure") triggers a coverity warning:
*** CID 1452808: Memory - illegal accesses (USE_AFTER_FREE)
/drivers/md/dm-zoned
From: Chao Yu
[ Upstream commit a37d0862d17411edb67677a580a6f505ec2225f6 ]
As Pavel Machek reported:
"We normally use -EUCLEAN to signal filesystem corruption. Plus, it is
good idea to report it to the syslog and mark filesystem as "needing
fsck" if filesystem can do that."
Still we need impro
From: Andi Kleen
Make sure to not free the name passed in by the caller, but free all the
allocated ids when parsing expressions.
The loop at the end knows that the first entry shouldn't be freed, so
make sure the caller name is the first entry.
Fixes
% perf stat -M
IpB,IpCall,IpTB,IPC,Reti
Em Tue, Sep 24, 2019 at 04:44:18PM +0200, Jiri Olsa escreveu:
> On Tue, Sep 24, 2019 at 07:08:56AM -0700, Andi Kleen wrote:
> > > > expr__ctx_init(&pctx);
> > > > + /* Must be first id entry */
> > > > + expr__add_id(&pctx, name, avg);
> > >
> > > hum, shouldn't u instead use s
On Tue, Sep 24, 2019 at 07:08:56AM -0700, Andi Kleen wrote:
> > > expr__ctx_init(&pctx);
> > > + /* Must be first id entry */
> > > + expr__add_id(&pctx, name, avg);
> >
> > hum, shouldn't u instead use strdup(name) instead of name?
>
> The cleanup loop later skips freeing the first entry.
aaa
> > expr__ctx_init(&pctx);
> > + /* Must be first id entry */
> > + expr__add_id(&pctx, name, avg);
>
> hum, shouldn't u instead use strdup(name) instead of name?
The cleanup loop later skips freeing the first entry.
-Andi
On Mon, Sep 23, 2019 at 04:33:39PM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> Make sure to not free the name passed in by the caller, but free
> all the allocated ids when parsing expressions.
>
> The loop at the end knows that the first entry shouldn't be freed,
> so make sure the caller n
1 - 100 of 1001 matches
Mail list logo
