ata in kernel space to probe for the height.
Signed-off-by: Meng Xu
---
Changes in V2
- Removed trailing spaces and splited lines with over 80 characters.
drivers/tty/vt/vt.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --
ata in kernel space to probe for the height.
Signed-off-by: Meng Xu
---
drivers/tty/vt/vt.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 2ebaba1..291e2b0 100644
--- a/driver
From: Meng Xu
`attr->size` after the second fetch `copy_from_user(attr, uattr, size)`,
can be different from what is initially fetched in and checked
`get_user(size, &uattr->size)` by racing condition in the userspace.
The issue and the patch are both similar to commit f12f42a
(in ker
Hi Peter,
I am sorry, I thought the patch is included in the forwarded
email. I just resent the patch. Please check.
Best Regards,
Meng
On 09/25/2017 03:31 AM, Peter Zijlstra wrote:
On Sat, Sep 23, 2017 at 10:05:56PM -0400, Meng Xu wrote:
Hi Peter and Ingo,
As a reminder, this is a very
= 2.
Whether this double-fetch situation is a security critical bug depends
on how cup->cu_msg is used later. However, given that it is hard to
enumerate all the possible use cases, a safer way might be to ensure
that the xid does not change across the fetches, which is what this
patch is for.
S
ata in kernel space to probe for the height.
Signed-off-by: Meng Xu
---
drivers/tty/vt/vt.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 2ebaba1..a43cecb 100644
--- a/driver
after the xdi_copy_from_user() in diva_xdi_write(),
which is what this patch is for.
Signed-off-by: Meng Xu
---
drivers/isdn/hardware/eicon/diva.c| 10 +-
drivers/isdn/hardware/eicon/os_4bri.c | 6 --
drivers/isdn/hardware/eicon/os_bri.c | 6 --
drivers/isdn/hardware/eicon/os_pr
version check after the second userspace fetch.
Signed-off-by: Meng Xu
---
net/tls/tls_main.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 60aff60..d4a7bc6 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
In __mptctl_ioctl() of file drivers/message/fusion/mptctl.c, there seems
to be a way to cause a confused deputy attack by racing condition in
userspace.
1. In the first userspace fetch, copy_from_user(&khdr, uhdr, sizeof(khdr),
a user process can put, say, 01, in uhdr->iocnum which will be fetche
,
Meng
> On Sep 19, 2017, at 11:23 AM, Meng Xu wrote:
>
> In coda_psdev_write(), the header of the buffer is fetched twice from the
> userspace. The first fetch is used to peek at the opcode and unique id while
> the second fetch copies the whole message. However, there could be
>
> On Sep 20, 2017, at 11:26 PM, Al Viro wrote:
>
> On Tue, Sep 19, 2017 at 11:11:11PM -0400, Meng Xu wrote:
>> Since right after the user copy, we are going to
>> memset(&karg, 0, sizeof(karg)), I guess an access_ok check is enough?
>
> access_ok() is *NOT*
Since right after the user copy, we are going to
memset(&karg, 0, sizeof(karg)), the copy_from_user is redundant
Signed-off-by: Meng Xu
---
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
b/drivers/scsi/mpt
md.
The patch explicitly overrides user_srbcmd->count after the second
userspace fetch with the value fibsize from the first userspace fetch.
In this way, it is assured that the relation, user_srbcmd->count stores
the size of the user_srbcmd buffer, still holds after the second fetch.
Si
Since right after the user copy, we are going to
memset(&karg, 0, sizeof(karg)), I guess an access_ok check is enough?
Signed-off-by: Meng Xu
---
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
b/dri
s in my capability.
Please let me know your thoughts on this matter. Thanks.
Best Regards,
Meng
> On Sep 12, 2017, at 6:49 PM, Meng Xu wrote:
>
> Hi Jerry,
>
> Thank you for the question. Yes, these double copies
> do seem to present an issue.
>
> __nd_ioctl() and acpi_
double-fetch behavior into two single fetches
decided by condition (lp->isdn_device < 0 || lp->isdn_channel <0).
A more detailed discussion can be found at
https://marc.info/?l=linux-kernel&m=150586376926123&w=2
Signed-off-by: Meng Xu
---
drivers/isdn
On 09/19/2017 05:31 PM, Dmitry Torokhov wrote:
On Mon, Sep 18, 2017 at 10:21 PM, Meng Xu wrote:
When in_compat_syscall(), a user could make type != UHID_CREATE when
get_user(type, buffer) [first fetch] and later make event->type ==
UHID_CREATE in copy_from_user(event, buffer, ...) [sec
between the two fetches and abort if changes to
the protobuf is detected across fetches.
Signed-off-by: Meng Xu
---
drivers/isdn/i4l/isdn_ppp.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/isdn/i4l/isdn_ppp.c b/drivers/isdn/i4l/isdn_ppp.c
index 6c44609
al sanity check and ensures that
what is recorded in kmsg->msg_controllen is the actual cmsg length.
Signed-off-by: Meng Xu
---
net/compat.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/compat.c b/net/compat.c
index 6ded6c8..2238171 100644
--- a/net/compat.c
+++ b/net/com
s what is fetched in originally. In other words, hdr.opcode and
hdr.unique do not change.
Signed-off-by: Meng Xu
---
fs/coda/psdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/coda/psdev.c b/fs/coda/psdev.c
index f40e395..b9dbdd8 100644
--- a/fs/coda/psdev.c
+++ b/fs/cod
free to let us know your opinion.
Best Regards,
Meng
On 09/19/2017 03:27 AM, Takashi Iwai wrote:
On Tue, 19 Sep 2017 07:21:56 +0200,
Meng Xu wrote:
The hm->h.size is intended to hold the actual size of the hm struct
that is copied from userspace and should always be <= sizeof(*hm).
hold
the value of the first fetch and override hm->h.size to msg_size
after the second fetch to maintain the relation.
Signed-off-by: Meng Xu
---
sound/pci/asihpi/hpioctl.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/sound/pci/asihpi/hpioctl.c b/sound/pc
ATE case and later cause undefined behaviors.
This patch enforces that event->type is overriden to the type value
copied in the first fetch and thus, mitigate this race condition attack.
Signed-off-by: Meng Xu
---
drivers/hid/uhid.c | 15 ---
1 file changed, 12 insertions(+), 3 del
, Meng Xu wrote:
From: Meng Xu
While examining the kernel source code, I found a dangerous operation that
could turn into a double-fetch situation (a race condition bug) where
the same userspace memory region are fetched twice into kernel with sanity
checks after the first fetch while missing
dules that have the same problem
has been acknowledged and fixed:
perf/core.c
https://marc.info/?l=linux-kernel&m=150442907017508&w=2
drivers/nvdimm/bus.c
https://marc.info/?l=linux-kernel&m=150454910315948&w=2
Best Regards,
Meng
On 08/23/2017 05:07 PM, Meng Xu wrote:
From: Meng Xu
2017 at 2:07 PM, Meng Xu wrote:
From: Meng Xu
While examining the kernel source code, I found a dangerous operation that
could turn into a double-fetch situation (a race condition bug) where
the same userspace memory region are fetched twice into kernel with sanity
checks after the first fet
This patch delays the check of nd_reserved2 to the actual endpoint
(acpi_nfit_ctl) that uses it, as a prevention of a potential
double-fetch bug.
Detailed discussion can be found at
https://marc.info/?l=linux-kernel&m=150421938113092&w=2
Signed-off-by: Meng Xu
---
drivers/acpi/nfit/co
From: Meng Xu
`attr->size` after the second fetch `copy_from_user(attr, uattr, size)`,
can be different from what is initially fetched in and checked
`get_user(size, &uattr->size)` by racing condition in the userspace.
The issue and the patch are both similar to commit f12f42a
(in ker
Commit-ID: f12f42acdbb577a12eecfcebbbec41c81505c4dc
Gitweb: http://git.kernel.org/tip/f12f42acdbb577a12eecfcebbbec41c81505c4dc
Author: Meng Xu
AuthorDate: Wed, 23 Aug 2017 17:07:50 -0400
Committer: Ingo Molnar
CommitDate: Tue, 29 Aug 2017 13:26:22 +0200
perf/core: Fix potential double
From: Meng Xu
While examining the kernel source code, I found a dangerous operation that
could turn into a double-fetch situation (a race condition bug) where
the same userspace memory region are fetched twice into kernel with sanity
checks after the first fetch while missing checks after the
From: Meng Xu
While examining the kernel source code, I found a dangerous operation that
could turn into a double-fetch situation (a race condition bug) where the same
userspace memory region are fetched twice into kernel with sanity checks after
the first fetch while missing checks after the
From: Meng Xu
While examining the kernel source code, I found a dangerous operation that
could turn into a double-fetch situation (a race condition bug) where
the same userspace memory region are fetched twice into kernel with sanity
checks after the first fetch while missing checks after the
32 matches
Mail list logo
