Hi,
I'm seeing this on latest linus/master:
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.7.0+ #
On 07/27/2016 12:38 PM, Ingo Molnar wrote:
* Vegard Nossum wrote:
I'm assuming you want to declare and initialise preempt_disable_ip at
once here, but it generates slightly worse code since it dereferences
current->preempt_disable_ip in the "fast path" (i.e. a sleeping
func
On 27 July 2016 at 11:15, Ingo Molnar wrote:
>
> * Vegard Nossum wrote:
[...]
> These two blocks could be merged trivially, avoiding an #ifdef pair ...
>> @@ -7541,6 +7550,9 @@ EXPORT_SYMBOL(__might_sleep);
>> void ___might_sleep(const char *file, int lin
that code (modulo
the capitalisation differences) is the reason why I also used 'if
(thread)' in my patch.
Vegard
-Original Message-
From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Moore, Robert
Sent: Tuesday, July 26, 2016 7:40 AM
To: Vegard Nossum ; Zheng, Lv
; Wy
On 26 July 2016 at 09:45, David Howells wrote:
> wrote:
>
>> If you will have no luck to repro issue, I will take a deeper look at it at
>> Friday and let you know asap
>
> Can you find out the line on which the crash happens? Load vmlinux into
If you pipe the Code: from the original report int
Preemption disabled at:[] rhashtable_walk_start+0x46/0x150
(Bug report: http://marc.info/?l=linux-netdev&m=146925979821849&w=2)
Cc: Peter Zijlstra
Cc: Paul E. McKenney
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Rusty Russel
Signed-off-by: Vegard Nossum
---
kernel/sched/cor
tipc_msg_create() callers.
Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum
---
net/tipc/socket.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index c49b8df..f9f5f3c 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -2180,7 +2
055b30 ]---
The problem is that irda_open_tsap() can fail and leave self->tsap = NULL,
and then irttp_connect_request() almost immediately dereferences it.
Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum
---
net/irda/af_irda.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions
Signed-off-by: Vegard Nossum
---
kernel/sched/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 97ee9ac..7171cf9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7573,6 +7573,7 @@ void ___might_sleep(const char *file, int line
e new state.
You can observe this when reading e.g.
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status
Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum
---
drivers/acpi/acpica/dsmethod.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers
a04bafec038 ]---
Cc: Al Viro
Signed-off-by: Vegard Nossum
---
net/9p/trans_virtio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 4acb1d5..f24b25c 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -5
Hi Dave + list,
I've started doing some trinity fuzzing and I'm seeing quite a few hung
tasks ("blocked for more than 120 seconds").
It started with unshare()/net_mutex which I found a few others running
into as well:
http://www.spinics.net/lists/trinity/msg00724.html
http://www.spinics.net/lis
ble sleep and checking if we're
supposed to stop whenever we wake up (like the rest of the code does).
Signed-off-by: Vegard Nossum
---
mm/kmemleak.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 04320d3..086292f 100644
--- a/mm/km
On 07/12/2016 04:27 PM, Andrey Ryabinin wrote:
On 07/12/2016 05:16 PM, Vegard Nossum wrote:
We really ought to be using \n with pr_*() so the 'general protection
fault...' starts on a line of its own. With this patch it looks better:
kasan: CONFIG_KASAN_INLINE enabled
t tainted 4.7.0-rc7+ #650
Cc: Andrey Ryabinin
Signed-off-by: Vegard Nossum
---
arch/x86/mm/kasan_init_64.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 1b1110f..0493c17 100644
--- a/arch/x86/mm/kasan_init_
On 07/11/2016 05:15 AM, Theodore Ts'o wrote:
On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
FYI, we noticed the following commit:
https://github.com/0day-ci/linux
Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
c
Commit-ID: eb019503569c8c701f1e9c70e848d99c6680839b
Gitweb: http://git.kernel.org/tip/eb019503569c8c701f1e9c70e848d99c6680839b
Author: Vegard Nossum
AuthorDate: Sun, 10 Jul 2016 19:14:01 +0200
Committer: Ingo Molnar
CommitDate: Sun, 10 Jul 2016 20:05:48 +0200
perf/x86: Fix bogus
This showed up as "6Failed to access..." here.
Fixes: 1b74dde7c47c ("x86/cpu: Convert printk(KERN_ ...) to
pr_(...)")
Cc: Chen Yucong
Signed-off-by: Vegard Nossum
---
arch/x86/events/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/even
On 25 June 2016 at 23:06, Vegard Nossum wrote:
> On 25 June 2016 at 17:04, Vegard Nossum wrote:
>> The test in this loop:
>>
>> for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
>>
>> was getting completely compiled out by my gcc, 7.0.0 201
On 25 June 2016 at 17:04, Vegard Nossum wrote:
> The test in this loop:
>
> for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
>
> was getting completely compiled out by my gcc, 7.0.0 20160520. The result
> was that the loop was going beyond the end of the bu
On 27 November 2015 at 05:30, Sasha Levin wrote:
> Hi,
>
> Fuzzing with syzkaller on the latest -next kernel produced this error:
>
> [ 1167.390182] WARNING: CPU: 14 PID: 607 at lib/debugobjects.c:263
> debug_print_object+0x1c4/0x1e0()
> (active state 0) object type: timer_list hint: delayed_work
hese are separate arrays.
Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum
---
drivers/base/firmware_class.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 773fc30..4dddf7f 100644
--- a/driv
ed-and-tested-by: Quentin Casasnovas
Cc: Markus Pargmann
Cc: Paul Clements
Cc: Pavel Machek
Cc: Jens Axboe
Cc: Al Viro
Signed-off-by: Vegard Nossum
---
drivers/block/nbd.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd
rrent directory (including subdirectories)
subdir-ccflags-y += $(CFLAGS_KCOV)
Cc: Dmitry Vyukov
Cc: Quentin Casasnovas
Signed-off-by: Vegard Nossum
---
lib/Kconfig.debug| 11 +++
scripts/Makefile.lib | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git
igned int i = 0; i < size; ++i) {
printf("%02x ", mem2[i]);
if (i % 32 == 31)
printf("\n");
}
close(fd);
return 0;
}
This patch is a collaboration
On 20 May 2016 at 16:35, Kangjie Lu wrote:
>> > Yes or no. According to my experiences, it depends on how
>> > it is initialized:
>> > if there are no variables but all constants in the bracket,
>> > a global initializer will be generated, which will zero the remaining
>> > bytes
>> > including p
On 20 May 2016 at 15:43, Kangjie Lu wrote:
>
>
> On Friday, May 20, 2016, Vegard Nossum wrote:
>>
>> On 19 May 2016 at 11:08, Jiri Slaby wrote:
>> > From: Kangjie Lu
>> >
>> > 3.12-stable review patch. If an
On 19 May 2016 at 11:08, Jiri Slaby wrote:
> From: Kangjie Lu
>
> 3.12-stable review patch. If anyone has any objections, please let me know.
>
> ===
>
> [ Upstream commit 5f8e44741f9f216e33736ea4ec65ca9ac03036e6 ]
>
> The stack object “map” has a total size of 32 bytes. Its last 4
>
fixed anyway.
To shield unsuspecting users from the possible DOS, we should mark this
BROKEN until somebody who actually uses this code can fix it.
Signed-off-by: Vegard Nossum
Link: https://lkml.org/lkml/2015/12/17/666
Cc: Eric Dumazet
Cc: Sasha Levin
Cc: David Miller
---
net/decnet/Kconfig | 1
Hi again Marek,
With your two patches on top of latest mainline I've run into this warning:
gadgetfs: connected
gadgetfs: disconnected
[ cut here ]
WARNING: CPU: 0 PID: 35 at drivers/usb/gadget/udc/dummy_hcd.c:674
dummy_free_request+0x92/0xa0()
CPU: 0 PID: 35 Comm: afl-
On 02/08/2016 01:15 PM, Marek Szyprowski wrote:
Gadgetfs driver called usb_gadget_unregister_driver unconditionally, even
if it didn't register it earlier due to other failures. This patch fixes
this.
Reported-by: Vegard Nossum
Signed-off-by: Marek Szyprowski
---
drivers/usb/gadget/l
On 02/08/2016 12:12 PM, Marek Szyprowski wrote:
Since commit 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb: gadget:
udc-core: independent registration of gadgets and gadget drivers") gadget
drivers can not assume that UDC drivers are already available on their
initialization. This broke the HACK
(fixed Felipe Balbi e-mail address)
On 02/08/2016 11:19 AM, Marek Szyprowski wrote:
Hello,
On 2016-02-08 10:46, Ruslan Bilovol wrote:
Hi Vegard,
On Mon, Feb 8, 2016 at 1:27 AM, Vegard Nossum
wrote:
Hi,
Using gadgetfs on latest mainline, I get the following NULL pointer
dereference:
BUG
Hi,
Using gadgetfs on latest mainline, I get the following NULL pointer
dereference:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] __list_del_entry+0x29/0xc0
PGD 34f067 PUD 355067 PMD 0
Oops: [#1] DEBUG_PAGEALLOC
CPU: 0 PID: 35 Comm: afl-fuzz Not tainted
ate.o):
In function `__timer_create_new':
(.text+0x168): undefined reference to `pthread_attr_setdetachstate'
[...]
Obviously we also need -lpthread for librt.a.
Signed-off-by: Vegard Nossum
---
scripts/link-vmlinux.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/
Hi all,
On latest linus/master I'm able to trigger the following KASAN warnings:
==
BUG: KASAN: out-of-bounds in filter_rcv+0xc3/0xa10 at addr 880014b4d680
Read of size 4 by task a.out/992
===
ointed-to memory
instead?
Anyway, this is a tentative patch that explains the issue and fixes
this particular problem -- dccp fuzzing now runs for minutes rather
than seconds before encountering a crash. I haven't tested any
real world workloads on this patch.
Signed-off-by: Vegard Nossum
Hi all,
I've been running into the following oops:
[ 1128.895622] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 1128.896010] IP: [< (null)>] (null)
[ 1128.896010] PGD 179ee067 PUD 189b1067 PMD 0
[ 1128.896010] Oops: 0010 [#1] PREEMPT SMP
[ 1128.
do a fork() which duplicates the non-empty
stdout buffer, then glibc flushes the duplicated buffer as each child
exits.
A simple workaround is to flush before forking.
Signed-off-by: Vegard Nossum
---
arch/um/os-Linux/start_up.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/um/os-
On 7 April 2014 at 21:18, David Miller wrote:
> From: Eric Dumazet
> Date: Sun, 06 Apr 2014 14:59:14 -0700
>
>> From: Eric Dumazet
>>
>> dnet_select_source() should make sure dn_ptr is not NULL.
>>
>> While looking at this decnet code, I believe I found a device
>> reference leak, lets fix it as
On 12/17/2015 02:01 AM, Eric Dumazet wrote:
On Wed, Dec 16, 2015 at 4:57 PM, Vegard Nossum wrote:
If you create a raw socket with a protocol of e.g. 0x1, then
inet_sk(sk)->inet_num will get set to 0 since it only has room for 16
bits. This causes problems further down the line as lots
_SYSCALL_64_fastpath+0x12/0x71
Code: Bad RIP value.
RIP [< (null)>] (null)
RSP
CR2:
---[ end trace bd60b4fe2edc2537 ]---
Signed-off-by: Vegard Nossum
Cc: Eric Dumazet
Cc:
---
net/ipv4/af_inet.c | 6 ++
1 file changed, 6 insertions(+
On 12/16/2015 11:17 PM, Richard Weinberger wrote:
Am 16.12.2015 um 21:59 schrieb Vegard Nossum:
An inverted return value check in hostfs_mknod() caused the function
to return success after handling it as an error (and cleaning up).
[...]
Applied! :-)
BTW: How did you create this patch? I
0054985>] fork_handler+0x85/0x90
Let's also get rid of the "cosmic ray protection" while we're at it.
Fixes: e9193059b1b3 "hostfs: fix races in dentry_name() and inode_name()"
Signed-off-by: Vegard Nossum
Cc: Jeff Dike
Cc: Al Viro
Cc: sta...@vger.kernel.org
On 12/14/2015 06:59 PM, Vegard Nossum wrote:
If a filesystem is mounted with errors=remount-ro, then orphan cleanup
can enter an infinite loop since the iput() inside the linked list
traversal doesn't actually always cause es->s_last_orphan to advance to
the next orphan inode (i.e. in
in for helping with the debugging.
Signed-off-by: Vegard Nossum
Cc: Jamie Iles
Cc: Quentin Casasnovas
Cc: sta...@vger.kernel.org
---
fs/ext4/super.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git fs/ext4/super.c fs/ext4/super.c
index c9ab67d..8952f
On 12/14/2015 10:52 AM, Jan Kara wrote:
On Thu 10-12-15 17:13:41, Vegard Nossum wrote:
Filesystem fuzzing revealed that we could get stuck in the
udf_process_sequence() loop.
The maximum limit was chosen arbitrarily but fixes the problem I saw.
Process nit: The patch is missing your Signed
GFP_NOFS);
The problem is that the 'depth' variable is a plain 'short', whereas
the value from the inode is a unsigned 16-bit number; in my case, its
value was -3328.
Simply changing the depth variable to be unsigned short is not
advisable, as that could still break
On 11/26/2015 09:30 AM, OGAWA Hirofumi wrote:
Vegard Nossum writes:
On 11/25/2015 10:54 PM, OGAWA Hirofumi wrote:
Vegard Nossum writes:
On 11/23/2015 11:21 PM, Richard Weinberger wrote:
Am 23.11.2015 um 08:55 schrieb Vegard Nossum:
With the attached vfat disk image (fuzzed), I get the
ave a similar problem?
Signed-off-by: Vegard Nossum
Cc: sta...@vger.kernel.org
Cc: Jan Kara
Cc: Quentin Casasnovas
Cc: Andrew Morton
---
fs/udf/inode.c | 13 +
1 file changed, 13 insertions(+)
diff --git fs/udf/inode.c fs/udf/inode.c
index 8d0b3ad..e1875f5 100644
--- fs/udf/inode.c
+
Filesystem fuzzing revealed that we could get stuck in the
udf_process_sequence() loop.
The maximum limit was chosen arbitrarily but fixes the problem I saw.
---
fs/udf/super.c | 14 ++
1 file changed, 14 insertions(+)
diff --git fs/udf/super.c fs/udf/super.c
index 81155b9..fd45537 1
On 8 December 2015 at 11:08, Suzuki K. Poulose wrote:
> On 08/12/15 07:58, Al Viro wrote:
>>
>> On Mon, Dec 07, 2015 at 10:49:05AM -0800, Linus Torvalds wrote:
>>>
>>> On Mon, Dec 7, 2015 at 10:05 AM, Suzuki K. Poulose
>>> wrote:
>
>
> ...
>
>> Anyway, the fix for 9p bogosity follows; it definite
Hi,
Mounting the attached hfs image (fuzzed) on the latest linus/master
gives me the following NULL pointer dereference:
# mount -o loop -t hfs hfs.0 /mnt/
hfs: unable to locate alternate MDB
hfs: continuing without an alternate MDB
BUG: unable to handle kernel NULL pointer dereference at 00
On 11/25/2015 10:54 PM, OGAWA Hirofumi wrote:
Vegard Nossum writes:
On 11/23/2015 11:21 PM, Richard Weinberger wrote:
Am 23.11.2015 um 08:55 schrieb Vegard Nossum:
With the attached vfat disk image (fuzzed), I get the following WARNING:
WARNING: CPU: 0 PID: 913 at fs/inode.c:275 drop_nlink
On 11/23/2015 11:21 PM, Richard Weinberger wrote:
Am 23.11.2015 um 08:55 schrieb Vegard Nossum:
With the attached vfat disk image (fuzzed), I get the following WARNING:
WARNING: CPU: 0 PID: 913 at fs/inode.c:275 drop_nlink+0x4b/0x50()
[...]
To trigger it, you have to do a rename("/mnt/
Hi,
With the attached vfat disk image (fuzzed), I get the following WARNING:
WARNING: CPU: 0 PID: 913 at fs/inode.c:275 drop_nlink+0x4b/0x50()
CPU: 0 PID: 913 Comm: a.out Not tainted 4.2.5+ #39
Stack:
e0931b50 60075412 e13981e8 0009
605cc684 e0931b60 605cf637
e0931bc0 60040f6d e0
On 11/14/2015 07:19 PM, OGAWA Hirofumi wrote:
Richard Weinberger writes:
Yes, it does fixes the problem here, but I can't really comment on the
correctness of the patch.
Thanks for the quick reponse,
I made cleanup and made sure fake_offset is corrected.
Richard, Signed-off-by was missed i
On 11/14/2015 11:32 AM, Richard Weinberger wrote:
On Sat, Nov 14, 2015 at 2:19 AM, Vegard Nossum wrote:
Hi,
Using the attached disk image I observe that getdents() never returns
the end of the directory, i.e. mounting the disk image on a loopback
device and running 'ls' under strac
Hi,
Using the attached disk image I observe that getdents() never returns
the end of the directory, i.e. mounting the disk image on a loopback
device and running 'ls' under strace shows an endless stream of:
getdents(3, /* 2 entries */, 32768) = 48
getdents(3, /* 2 entries */, 32768) = 4
On 9 July 2014 23:44, Andi Kleen wrote:
> Dave Hansen writes:
>>
>> You're also claiming that "KASAN is better than all of
>
> better as in finding more bugs, but surely not better as in
> "do so with less overhead"
>
>> CONFIG_DEBUG_PAGEALLOC". So should we just disallow (or hide)
>> DEBUG_PAGE
On 05/09/2014 11:52 AM, Xishi Qiu wrote:
On 2014/5/9 15:57, Xishi Qiu wrote:
OS boot with kmemcheck=0, then set 1, do something, set 0, do something, set
1...
then I got the WARNING log. Does kmemcheck support dynamicly adjust?
Thanks,
Xishi Qiu
[ 20.200305] igb: eth0 NIC Link is Up 1000 M
On 04/01/2014 12:30 PM, Hannes Frederic Sowa wrote:
On Tue, Apr 01, 2014 at 12:08:18PM +0200, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest
().
Fixes: f9a23c84486ed35 ("isdnloop: use strlcpy() instead of strcpy()")
Cc: Dan Carpenter
Cc: David S. Miller
Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum
---
drivers/isdn/isdnloop/isdnloop.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/isd
On 31 March 2014 15:36, Dan Carpenter wrote:
> On Mon, Mar 31, 2014 at 02:56:07PM +0200, Vegard Nossum wrote:
>> Ping, Dave? Just making sure this doesn't fall through the cracks. I
>> don't see the patch applied anywhere yet and without this patch we
>> still ha
On 7 March 2014 11:56, Vegard Nossum wrote:
> Both the in-kernel and BSD strlcpy() require that the source string is
> NUL terminated. We could use strncpy() + explicitly terminate the result,
> but this relies on src and dest having the same size, so the safest thing
> to do seems t
On 03/17/2014 10:51 AM, Michal Hocko wrote:
On Mon 17-03-14 17:19:33, Xishi Qiu wrote:
OS boot failed when set cmdline kmemcheck=1. The reason is that
NMI handlers will access the memory from kmalloc(), this will cause
page fault, because memory from kmalloc() is tracked by kmemcheck.
watchdog_
On 03/07/2014 12:52 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 12:42:12PM +0100, Vegard Nossum wrote:
On 03/07/2014 12:26 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL
On 03/07/2014 12:26 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated.
No. You're obviously wrong. What on earth?
Well, from lib/string.c:
size_t strlcpy(char
().
Fixes: f9a23c84486ed35 ("isdnloop: use strlcpy() instead of strcpy()")
Cc: Dan Carpenter
Cc: David S. Miller
Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum
---
drivers/isdn/isdnloop/isdnloop.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/isd
On 26 February 2014 09:43, Peter Zijlstra wrote:
> On Wed, Feb 19, 2014 at 02:24:41PM -0800, David Rientjes wrote:
>> On Wed, 19 Feb 2014, Xishi Qiu wrote:
>>
>> > Here is a warning, I don't whether it is relative to my hardware.
>> > If set "kmemcheck=1 nowatchdog", it can boot.
>> >
>> > code:
>
Commit-ID: 4efbc454ba68def5ef285b26ebfcfdb605b52755
Gitweb: http://git.kernel.org/tip/4efbc454ba68def5ef285b26ebfcfdb605b52755
Author: Vegard Nossum
AuthorDate: Sun, 16 Feb 2014 22:24:17 +0100
Committer: Thomas Gleixner
CommitDate: Fri, 21 Feb 2014 21:27:10 +0100
sched: Fix
On 17 February 2014 03:34, Xishi Qiu wrote:
> If we want to debug the kernel memory, we should turn on CONFIG_KMEMCHECK
> and rebuild the kernel. This always takes a long time and sometimes
> impossible, e.g. users don't have the kernel source code or the code
> is different from "www.kernel.org"
On 02/17/2014 01:59 PM, Jan Kara wrote:
Hello,
On Sat 15-02-14 22:39:38, Vegard Nossum wrote:
It would seem that
commit 7053aee26a3548ebaba046ae2e52396ccf56ac6c
Author: Jan Kara
Date: Tue Jan 21 15:48:14 2014 -0800
fsnotify: do not share events between notification groups
From: Vegard Nossum
We're copying the on-stack structure to userspace, but forgot to give
the right number of bytes to copy. This allows the calling process to
obtain up to PAGE_SIZE bytes from the stack (and possibly adjacent
kernel memory).
This fix copies only as much as we actually ha
Hi,
There seems to be a bug in ext4 where the i_crtime of struct
ext4_inode_info is not initialised, so (some) creation times contain
essentially random values. Here's a report from kmemcheck:
[ 92.402035] WARNING: kmemcheck: Caught 64-bit read from uninitialized
memory (8800168ab208)
Hi,
It would seem that
commit 7053aee26a3548ebaba046ae2e52396ccf56ac6c
Author: Jan Kara
Date: Tue Jan 21 15:48:14 2014 -0800
fsnotify: do not share events between notification groups
introduced a bug where the cookie field of struct inotify_event never
gets initialised. In particular,
On 2 January 2014 02:34, Xishi Qiu wrote:
> On 2013/12/31 18:12, Vegard Nossum wrote:
>> On 31 December 2013 09:32, Xishi Qiu wrote:
>>> Add a new command-line kmemcheck value: kmemcheck=3 (disable the feature),
>>> this is the same effect as CONFIG_KMEMCHECK disable
(Oops, resend to restore Cc.)
Hi,
On 31 December 2013 09:32, Xishi Qiu wrote:
> Add a new command-line kmemcheck value: kmemcheck=3 (disable the feature),
> this is the same effect as CONFIG_KMEMCHECK disabled.
> After doing this, we can enable/disable kmemcheck feature in one vmlinux.
Could yo
On 12/13/2013 06:09 AM, James Morris wrote:
On Thu, 12 Dec 2013, Greg Kroah-Hartman wrote:
On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> - who will keep adding these triggers going forward?
I think we'd need to ha
On 12/13/2013 12:50 AM, Ryan Mallon wrote:
On 13/12/13 08:13, Kees Cook wrote:
On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
The idea is simple -- since different kernel versions are vulnerable to
different roo
On 12/12/2013 10:13 PM, Kees Cook wrote:
On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
The idea is simple -- since different kernel versions are vulnerable to
different root exploits, hackers most likely try mul
On 12/12/2013 08:06 PM, Theodore Ts'o wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
The idea is simple -- since different kernel versions are vulnerable to
different root exploits, hackers most likely try multiple exploits before
they actually succeed.
Suppos
From: Vegard Nossum
See cc9b17ad29ecaa20bfe426a8d4dbfb94b13ff1cc.
Cc: Jason Wang
Cc: David S. Miller
Signed-off-by: Vegard Nossum
---
net/core/sock.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 0b39e7a..c16246f 100644
From: Vegard Nossum
See 6f24f892871acc47b40dd594c63606a17c714f77.
Cc: Greg Kroah-Hartman
Signed-off-by: Vegard Nossum
---
fs/hfsplus/catalog.c |2 ++
fs/hfsplus/dir.c |3 +++
2 files changed, 5 insertions(+)
diff --git a/fs/hfsplus/catalog.c b/fs/hfsplus/catalog.c
index 968ce41
From: Vegard Nossum
The idea is simple -- since different kernel versions are vulnerable to
different root exploits, hackers most likely try multiple exploits before
they actually succeed.
Fixing an exploitable kernel bug usually means adding a check to see if
what a userspace program tried to
From: Vegard Nossum
See 8176cced706b5e5d15887584150764894e94e02f.
Cc: Tommi Rantala
Cc: Ingo Molnar
Signed-off-by: Vegard Nossum
---
kernel/events/core.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 953c143..32b9383 100644
--- a
From: Vegard Nossum
See 3118a4f652c7b12c752f3222af0447008f9b2368.
Cc: Kees Cook
Cc: Daniel Vetter
Signed-off-by: Vegard Nossum
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
From: Vegard Nossum
See 6708075f104c3c9b04b23336bb0366ca30c3931b and
e3211c120a85b792978bcb4be7b2886df18d27f0.
Cc: "Eric W. Biederman"
Cc: Andy Lutomirski
Signed-off-by: Vegard Nossum
---
kernel/user_namespace.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletion
From: Vegard Nossum
See c903f0456bc69176912dee6dd25c6a66ee1aed00.
Cc: Alan Cox
Cc: Ingo Molnar
Signed-off-by: Vegard Nossum
---
arch/x86/kernel/msr.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 88458fa
From: Vegard Nossum
Signed-off-by: Vegard Nossum
---
include/uapi/linux/audit.h |1 +
security/exploit.c | 16
2 files changed, 17 insertions(+)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 75cef3f..65811d4 100644
--- a/include/uapi
From: Vegard Nossum
See bc5b8a9003132ae44559edd63a1623b7b99dfb68.
Cc: Dan Carpenter
Signed-off-by: Vegard Nossum
---
fs/hfs/trans.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/hfs/trans.c b/fs/hfs/trans.c
index b1ce4c7..2fe83f0 100644
--- a/fs/hfs/trans.c
Hi,
On Fri, 13 Jul 2012 00:33:07 +0300, Sami Liedes wrote:
> Hi,
>
> Kernel 3.4.4 with kmemcheck enabled does not correctly boot on my
> system, which is a x86-64, Core i7 Sandy Bridge computer with Asus
> P8P67-EVO motherboard. The errors seem to be related to ACPI, but
> there may be other thin
Hello!
On Mon, Feb 25, 2008 at 8:23 PM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> CC arch/x86/kernel/traps_32.o
> /home/jeremy/hg/xen/paravirt/linux/arch/x86/kernel/traps_32.c:59:27: error:
> asm/kmemcheck.h: No such file or directory
>
>
> asm-x86/kmemcheck.h does seem to be comp
On Sat, Feb 23, 2008 at 7:31 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> O> I don't see the connection between (no-)smp and ata. Something with
>
> > interrupt routing/IPI, missing irq ack? Booting another !SMP kernel
> > works fine. The problem also exists in 2.6.24-rc2.
>
> Almost certainly inter
On Sat, Feb 23, 2008 at 7:31 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> O> I don't see the connection between (no-)smp and ata. Something with
>
> > interrupt routing/IPI, missing irq ack? Booting another !SMP kernel
> > works fine. The problem also exists in 2.6.24-rc2.
>
> Almost certainly inter
her !SMP kernel
works fine. The problem also exists in 2.6.24-rc2.
Kind regards,
Vegard Nossum
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ple
Hi again,
This patch is different (probably better?), but touches all users and
all architectures implementing stacktrace saving. If you want it, it's
here... :-)
Kind regards,
Vegard Nossum
From 98d928d337dca6326773d43da90a268e5ff0c098 Mon Sep 17 00:00:00 2001
From: Vegard Nossum &l
users of save_stack_trace() and all arches saving this
information to change.
Kind regards,
Vegard Nossum
From 5edfd896c5f0d728111df3d8cae729a375f29d3c Mon Sep 17 00:00:00 2001
From: Vegard Nossum <[EMAIL PROTECTED]>
Date: Fri, 22 Feb 2008 19:23:58 +0100
Subject: [PATCH] x86: don&
Hi.
make randconfig (v2.6.25-rc2 + unrelated patches) found this:
CC [M] sound/drivers/opl3/opl3_synth.o
sound/drivers/opl3/opl3_synth.c: In function ‘snd_opl3_find_patch’:
sound/drivers/opl3/opl3_synth.c:308: error: ‘OPL3_PATCH_HASH_SIZE’ undeclared
(first use in this function)
sound/driver
On Thu, Feb 14, 2008 at 10:49 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> The ifdefs are quite ugly. I would recommend to define standard
> functions (kmemcheck_init_zero or similar and an own __GFP flag) that can
> be used without ifdef and easily nop'ed out on !KMEMCHECK kernels.
Yes, they ar
201 - 300 of 375 matches
Mail list logo
