Reviewed-by: Huacai Chen
On Wed, Jun 11, 2025 at 7:28 PM Thomas Weißschuh
wrote:
>
> Not all tasks have an ABI associated or vDSO mapped,
> for example kthreads never do.
> If such a task ever ends up calling stack_top(), it will derefence the
> NULL ABI pointer and crash.
&
Not all tasks have an ABI associated or vDSO mapped,
for example kthreads never do.
If such a task ever ends up calling stack_top(), it will derefence the
NULL ABI pointer and crash.
This can for example happen when using kunit:
mips_stack_top+0x28/0xc0
arch_pick_mmap_layout+0x190/0x220
p calling stack_top(), it will derefence the
> > NULL ABI pointer and crash.
> >
> > This can for example happen when using kunit:
> >
> > mips_stack_top+0x28/0xc0
> > arch_pick_mmap_layout+0x190/0x220
> > kunit_vm_mmap_init+0xf8/0x13
Not all tasks have an ABI associated or vDSO mapped,
for example kthreads never do.
If such a task ever ends up calling stack_top(), it will derefence the
NULL ABI pointer and crash.
This can for example happen when using kunit:
mips_stack_top+0x28/0xc0
arch_pick_mmap_layout+0x190/0x220
Hi, Thomas,
On Tue, Apr 15, 2025 at 3:10 PM Thomas Weißschuh
wrote:
>
> Not all tasks have an ABI associated or vDSO mapped,
> for example kthreads never do.
> If such a task ever ends up calling stack_top(), it will derefence the
> NULL ABI pointer and crash.
>
> This c
On Tue, 15 Apr 2025 at 15:10, Thomas Weißschuh
wrote:
>
> Not all tasks have an ABI associated or vDSO mapped,
> for example kthreads never do.
> If such a task ever ends up calling stack_top(), it will derefence the
> NULL ABI pointer and crash.
>
> This can for example ha
ends up calling stack_top(), it will derefence the
> > NULL vdso pointer and crash.
> >
> > This can for example happen when using kunit:
> >
> > mips_stack_top+0x28/0xc0
> > arch_pick_mmap_layout+0x190/0x220
> > kunit_vm_mmap_init+0xf
Hi, Thomas,
On Mon, Apr 14, 2025 at 4:29 PM Thomas Weißschuh
wrote:
>
> Not all tasks have an ABI associated or vDSO mapped,
> for example kthreads never do.
> If such a task ever ends up calling stack_top(), it will derefence the
> NULL vdso pointer and crash.
>
> This c
Not all tasks have an ABI associated or vDSO mapped,
for example kthreads never do.
If such a task ever ends up calling stack_top(), it will derefence the
NULL vdso pointer and crash.
This can for example happen when using kunit:
mips_stack_top+0x28/0xc0
arch_pick_mmap_layout+0x190/0x220
On Mon, 14 Oct 2024 at 19:36, Thomas Weißschuh
wrote:
>
> Not all tasks have a vDSO mapped, for example kthreads never do.
> If such a task ever ends up calling stack_top(), it will derefence the
> NULL vdso pointer and crash.
>
> This can for example happe
; > > Not all tasks have a vDSO mapped, for example kthreads never do.
> > > If such a task ever ends up calling stack_top(), it will derefence the
> > > NULL vdso pointer and crash.
> > >
> > > This can for example happen when using kunit:
> > >
>
t 7:36 PM Thomas Weißschuh
> wrote:
> >
> > Not all tasks have a vDSO mapped, for example kthreads never do.
> > If such a task ever ends up calling stack_top(), it will derefence the
> > NULL vdso pointer and crash.
> >
> > This can for example happen when
p calling stack_top(), it will derefence the
> NULL vdso pointer and crash.
>
> This can for example happen when using kunit:
>
> [<90203874>] stack_top+0x58/0xa8
> [<902956cc>] arch_pick_mmap_layout+0x164/0x220
> [<9000
Not all tasks have a vDSO mapped, for example kthreads never do.
If such a task ever ends up calling stack_top(), it will derefence the
NULL vdso pointer and crash.
This can for example happen when using kunit:
[<90203874>] stack_top+0x58/0xa8
[<900
On Tue, Aug 20, 2024 at 02:42:31PM GMT, Gokul Sriram Palanisamy wrote:
> From: Vignesh Viswanathan
>
> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>
> For some targets like IPQ9574
From: Vignesh Viswanathan
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition due to which the crash reason
We have noticed an issue when a uprobe is attached to a valid file offset, and
the content of that file is modified (with no inode change).
Executing from a modified file while the uprobe is attached may cause a process
to crash. The crash happens if the probed offset is invalid for the new
t; __trace_remove_event_call() -> event_remove() ->
>>> remove_event_from_tracers()
>>>
>>> Where remove_event_from_tracers() loops over all the instances and will set
>>> each of the file pointers flags associated to the event: EVENT_FILE_FL_FREED
>
acers()
> >
> > Where remove_event_from_tracers() loops over all the instances and will set
> > each of the file pointers flags associated to the event: EVENT_FILE_FL_FREED
> >
> > Then it returns back to destroy_user_event() that would free the event.
> >
> &g
with false, that will then call:
trace_remove_event_call() -> probe_remove_event_call() ->
__trace_remove_event_call() -> event_remove() ->
remove_event_from_tracers()
Where remove_event_from_tracers() loops over all the instances and will set
each of the file pointers flags associated to the even
On 25.07.24 22:15, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 21:42:41 +0200
> Mathias Krause wrote:
>
>> Right. But the point is, that 'event_call' is really some '&user->call'.
>> With 'user' being free'd memory, what gives? Dereferencing 'event_call'
>> is UB, so this function is doomed to fa
On Thu, 25 Jul 2024 21:42:41 +0200
Mathias Krause wrote:
> Right. But the point is, that 'event_call' is really some '&user->call'.
> With 'user' being free'd memory, what gives? Dereferencing 'event_call'
> is UB, so this function is doomed to fail because it cannot know if its
> only argument p
On 25.07.24 21:05, Steven Rostedt wrote:
> Here's the proper fix:
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 6ef29eba90ce..3a2d2ff1625b 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -3140,8 +3140,10 @@ EXPORT_SYMBOL_GPL(
On 25.07.24 21:05, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 20:12:33 +0200
> Mathias Krause wrote:
@@ -973,6 +975,11 @@ size_t copy_nofault(void *addr, size_t bytes, struct
iov_iter *i)
static struct list_head *user_event_get_fields(struct trace_event_call
*call)
{
On Thu, 25 Jul 2024 20:12:33 +0200
Mathias Krause wrote:
>
> >
> >> +
> >>if (WARN_ON_ONCE(!schedule_work(&user->put_work))) {
> >>/*
> >> * If we fail we must wait for an admin to attempt delete or
> >> @@ -973,6 +975,11 @@ size_t copy_nofault(void *addr, size_t b
On 25.07.24 19:16, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 13:10:21 -0400
> Steven Rostedt wrote:
>>
>> diff --git a/kernel/trace/trace_events_user.c
>> b/kernel/trace/trace_events_user.c
>> index 3a2b46847c8b..e9ed2826ff46 100644
>> --- a/kernel/trace/trace_events_user.c
>> +++ b/kernel/trac
On Thu, 25 Jul 2024 13:10:21 -0400
Steven Rostedt wrote:
>
> diff --git a/kernel/trace/trace_events_user.c
> b/kernel/trace/trace_events_user.c
> index 3a2b46847c8b..e9ed2826ff46 100644
> --- a/kernel/trace/trace_events_user.c
> +++ b/kernel/trace/trace_events_user.c
> @@ -321,6 +321,8 @@ static
On Thu, 25 Jul 2024 22:00:14 +0530
Ajay Kaher wrote:
> Thread A (read event) Thread B (remove event)
>
> . worker_thread()
> . delayed_destroy_user_event()
> .
On Thu, 25 Jul 2024 21:45:03 +0530
Ajay Kaher wrote:
> On Mon, Jul 22, 2024 at 5:38 PM Mathias Krause wrote:
> >
> > On 22.07.24 13:13, Ajay Kaher wrote:
> > > On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause
> > > wrote:
> > >>
> > >> I noticed, the user events ftrace selftest is crashing e
On Thu, Jul 25, 2024 at 9:45 PM Ajay Kaher wrote:
>
> On Mon, Jul 22, 2024 at 5:38 PM Mathias Krause wrote:
> >
> > On 22.07.24 13:13, Ajay Kaher wrote:
> > > On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause
> > > wrote:
> > >>
> > >> I noticed, the user events ftrace selftest is crashing every n
On Mon, Jul 22, 2024 at 5:38 PM Mathias Krause wrote:
>
> On 22.07.24 13:13, Ajay Kaher wrote:
> > On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause
> > wrote:
> >>
> >> I noticed, the user events ftrace selftest is crashing every now and
> >> then in our automated tests. Digging into, I found that
On Mon, Jul 22, 2024 at 5:38 PM Mathias Krause wrote:
>
> On 22.07.24 13:13, Ajay Kaher wrote:
> > On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause
> > wrote:
> >>
> >> I noticed, the user events ftrace selftest is crashing every now and
> >> then in our automated tests. Digging into, I found that
On 23.07.24 16:43, Steven Rostedt wrote:
> On Fri, 19 Jul 2024 22:47:01 +0200
> Mathias Krause wrote:
>
>> Beside the obvious bug, I noticed the following (not fixing the issue,
>> tho):
>>
>> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
>> index 5d88c184f0fc..687ad0a26458 100
On Fri, 19 Jul 2024 22:47:01 +0200
Mathias Krause wrote:
> Beside the obvious bug, I noticed the following (not fixing the issue,
> tho):
>
> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
> index 5d88c184f0fc..687ad0a26458 100644
> --- a/fs/tracefs/event_inode.c
> +++ b/fs/tra
On Fri, 19 Jul 2024 22:47:01 +0200
Mathias Krause wrote:
> Subject: [PATCH] eventfs: Don't return NULL in eventfs_create_dir()
>
> Commit 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing
> ei->dentry") added another check, testing if the parent was freed after
> we released the mutex
On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause wrote:
>
> Hi Steven, Ajay,
>
> [ @Cc list: I found out issues with tracefs have been reported /
> attempted to get fixed in the past, so you may be interested. ]
>
> I noticed, the user events ftrace selftest is crashing every now and
> then in our
: Don't return NULL in eventfs_create_dir()
>
> Commit 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing
> ei->dentry") added another check, testing if the parent was freed after
> we released the mutex. If so, the function returns NULL. However, all
> callers expect it to either return a valid pointer or an error pointer,
> at least since commit 5264a2f4bb3b ("tracing: Fix a NULL vs IS_ERR() bug
> in event_subsystem_dir()"). Returning NULL will therefore fail the error
> condition check in the caller.
>
> Fix this by substituting the NULL return value with a fitting error
> pointer.
>
> Fixes: 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing
> ei->dentry")
> Cc: Dan Carpenter
> Signed-off-by: Mathias Krause
Reviewed-by: Dan Carpenter
Yeah. It's unfortunate how the timing worked where we merged
conflicting patches at basically the same time. In an ideal would we
would have found this bug through static analysis but the callers don't
dereference "ei" so we can't tell if it's intentional or not. This
bug seems like it would be annoying to hit but I'm not sure how if it
would lead to a crash.
Anyway, thanks for the patch. I hope Steven is able to fix the more
complicated bug.
regards,
dan carpenter
Hi Steven, Ajay,
[ @Cc list: I found out issues with tracefs have been reported /
attempted to get fixed in the past, so you may be interested. ]
I noticed, the user events ftrace selftest is crashing every now and
then in our automated tests. Digging into, I found that the following
is trigger
to the validate persistent buffer code.
Changes since v3:
https://lore.kernel.org/all/20240606211735.684785...@goodmis.org/
- Removed an unused variable
- Fixed enable_instances() as the path without memory using the memory location
in the command line parameter passed in "tok" whe
Changes since v3:
https://lore.kernel.org/all/20240606211735.684785...@goodmis.org/
- Removed an unused variable
- Fixed enable_instances() as the path without memory using the memory location
in the command line parameter passed in "tok" where it now needs to be
"name" for
Enjoy...
Changes since v3:
https://lore.kernel.org/all/20240606211735.684785...@goodmis.org/
- Removed an unused variable
- Fixed enable_instances() as the path without memory using the memory location
in the command line parameter passed in "tok" where it now needs to be
"
This is a way to map a ring buffer instance across reboots.
The requirement is that you have a memory region that is not erased.
I tested this on a Debian VM running on qemu on a Debian server,
and even tested it on a baremetal box running Fedora. I was
surprised that it worked on the baremetal b
This is a way to map a ring buffer instance across reboots.
The requirement is that you have a memory region that is not erased.
I tested this on a Debian VM running on qemu on a Debian server,
and even tested it on a baremetal box running Fedora. I was
surprised that it worked on the baremetal b
ime, the configure vector is
> still VIRTIO_NO_VECTOR) and call virtio_pci_set_guest_notifiers() with
> assgin= true, so the irqfd for vector 0 is still not "init" during this
> process
>
> 4. The system continues to boot,set the vector back to 0, and
> msix_fire_vector_notifi
guest called vhost_net_start, (at this time, the configure
> vector is still VIRTIO_NO_VECTOR), vector 0 still was not "init".
> The guest system continued to boot, set the vector back to 0, and then met
> the crash.
>
> To fix this, we need to call the function "kvm_virt
quot;.
The guest system continued to boot, set the vector back to 0, and then met the
crash.
To fix this, we need to call the function "kvm_virtio_pci_vector_use_one()"
when the vector changes back from VIRTIO_NO_VECTOR
(gdb) bt
0 __pthread_kill_implementation (threadid=,
signo=signo@en
" during this process
4. The system continues to boot,set the vector back to 0, and
msix_fire_vector_notifier() was triggered
unmask the vector 0 and then met the crash
[msix_fire_vector_notifier] 112 called vector 0 is_masked 1
[msix_fire_vector_notifier] 112 called vector 0 is_masked 0
To
On Sat, 9 Mar 2024 12:40:51 -0800
Kees Cook wrote:
> The part I'd like to get wired up sanely is having pstore find the
> nvdimm area automatically, but it never quite happened:
> https://lore.kernel.org/lkml/CAGXu5jLtmb3qinZnX3rScUJLUFdf+pRDVPjy=cs4kutw9tl...@mail.gmail.com/
The automatic detec
On Sat, Mar 09, 2024 at 01:51:16PM -0500, Steven Rostedt wrote:
> On Sat, 9 Mar 2024 10:27:47 -0800
> Kees Cook wrote:
>
> > On Tue, Mar 05, 2024 at 08:59:10PM -0500, Steven Rostedt wrote:
> > > This is a way to map a ring buffer instance across reboots.
> >
> > As mentioned on Fedi, check out
On Sat, 9 Mar 2024 10:27:47 -0800
Kees Cook wrote:
> On Tue, Mar 05, 2024 at 08:59:10PM -0500, Steven Rostedt wrote:
> > This is a way to map a ring buffer instance across reboots.
>
> As mentioned on Fedi, check out the persistent storage subsystem
> (pstore)[1]. It already does what you're s
On Tue, Mar 05, 2024 at 08:59:10PM -0500, Steven Rostedt wrote:
> This is a way to map a ring buffer instance across reboots.
As mentioned on Fedi, check out the persistent storage subsystem
(pstore)[1]. It already does what you're starting to construct for RAM
backends (but also supports reed-sol
On 3/6/2024 9:25 AM, Bjorn Andersson wrote:
> On Wed, Dec 20, 2023 at 11:25:11AM +0530, Vignesh Viswanathan wrote:
>> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
>> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>>
>> For so
On Wed, Dec 20, 2023 at 11:25:11AM +0530, Vignesh Viswanathan wrote:
> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>
> For some targets like IPQ9574 and IPQ5332, crash reason information is
I forgot to add [POC] to the topic.
All these patches are a proof of concept.
-- Steve
trace-cmd and perf could
calculate the current kallsyms from the old pointers.
Finally, this is still a proof of concept. How to create this memory
mapping isn't decided yet. In this patch set I simply hacked into
kexec crash code and hard coded an address that worked for one of my
machines (for t
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition due to which the crash reason is
not printed in the
On 12/18/2023 9:26 PM, Mukesh Ojha wrote:
>
>
> On 12/18/2023 11:40 AM, Vignesh Viswanathan wrote:
>> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
>> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>>
>> For some target
On 12/18/2023 11:40 AM, Vignesh Viswanathan wrote:
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition due to which the crash reason is
not printed in the
On 12/18/2023 11:36 AM, Vignesh Viswanathan wrote:
> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>
> For some targets like IPQ9574 and IPQ5332, crash reason information is
> present in
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition due to which the crash reason is
not printed in the
On 12/18/2023 2:13 AM, Bjorn Andersson wrote:
> On Sat, Nov 25, 2023 at 12:20:59AM +0530, Vignesh Viswanathan wrote:
>> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
>> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>>
>> For so
On Sat, Nov 25, 2023 at 12:20:59AM +0530, Vignesh Viswanathan wrote:
> q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
> information from SMEM global partition (QCOM_SMEM_HOST_ANY).
>
> For some targets like IPQ9574 and IPQ5332, crash reason information is
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition due to which the crash reason is
not printed in the
On Sun, Aug 22, 2021 at 4:49 AM wrote:
>
> From: sumiyawang
>
> kernel will crash when use after free the ioremap space,
> which is triggered by ndctl destroy-namespace while some IO operations
> exist.
> The sequence of pmem driver release chain should be changed:
> free
From: sumiyawang
kernel will crash when use after free the ioremap space,
which is triggered by ndctl destroy-namespace while some IO operations
exist.
The sequence of pmem driver release chain should be changed:
freeze the queue and wait io finished first, then iounmap.
[47202.018374] BUG
Committer: Borislav Petkov
CommitterDate: Tue, 20 Apr 2021 17:32:46 +02:00
x86/crash: Fix crash_setup_memmap_entries() out-of-bounds access
Commit in Fixes: added support for kexec-ing a kernel on panic using a
new system call. As part of it, it does prepare a memory map for the new
kernel
Hi, Jiaxun
On 04/20/2021 09:11 AM, Jiaxun Yang wrote:
在 2021/4/19 18:56, Youling Tang 写道:
From: Huacai Chen
kexec-tools use mem=X@Y to pass usable memories to crash kernel, but in
commit a94e4f24ec836c8984f83959 ("MIPS: init: Drop boot_mem_map") all
BIOS passed memories are
在 2021/4/19 18:56, Youling Tang 写道:
From: Huacai Chen
kexec-tools use mem=X@Y to pass usable memories to crash kernel, but in
commit a94e4f24ec836c8984f83959 ("MIPS: init: Drop boot_mem_map") all
BIOS passed memories are removed by early_parse_mem(). I think this is
reasonable fo
From: Huacai Chen
kexec-tools use mem=X@Y to pass usable memories to crash kernel, but in
commit a94e4f24ec836c8984f83959 ("MIPS: init: Drop boot_mem_map") all
BIOS passed memories are removed by early_parse_mem(). I think this is
reasonable for a normal kernel but not for a cr
On 04/19/21 at 10:52am, Borislav Petkov wrote:
> Here's an attempt to explain what this fixes:
>
> ---
> From: Mike Galbraith
> Date: Fri, 16 Apr 2021 14:02:07 +0200
> Subject: [PATCH] x86/crash: Fix crash_setup_memmap_entries() out-of-bounds
> access
>
> Co
Here's an attempt to explain what this fixes:
---
From: Mike Galbraith
Date: Fri, 16 Apr 2021 14:02:07 +0200
Subject: [PATCH] x86/crash: Fix crash_setup_memmap_entries() out-of-bounds
access
Commit in Fixes: added support for kexec-ing a kernel on panic using a
new system call. As part
This patch allows Linux to act as a crash kernel for use with
kdump. Userspace will let the crash kernel know about the
memory region it can use through linux,usable-memory property
on the /memory node (overriding its reg property), and about the
memory region where the elf core header of the
On Fri, 2021-04-16 at 23:44 +0200, Thomas Gleixner wrote:
>
> Can all of you involved stop this sandpit fight and do something useful
> to fix that obvious bug already?
?? We're not fighting afaik. Boris hated my changelog enough to offer
to write a better one, and I'm fine with that. It's a sev
On Fri, Apr 16 2021 at 17:13, Mike Galbraith wrote:
> On Fri, 2021-04-16 at 16:44 +0200, Borislav Petkov wrote:
>> On Fri, Apr 16, 2021 at 03:16:07PM +0200, Mike Galbraith wrote:
>> > On Fri, 2021-04-16 at 14:16 +0200, Borislav Petkov wrote:
>> > >
>> > > Please be more verbose and structure your c
On Fri, 2021-04-16 at 16:44 +0200, Borislav Petkov wrote:
> On Fri, Apr 16, 2021 at 03:16:07PM +0200, Mike Galbraith wrote:
> > On Fri, 2021-04-16 at 14:16 +0200, Borislav Petkov wrote:
> > >
> > > Please be more verbose and structure your commit message like this:
> >
> > Hrmph, I thought it was t
On Fri, Apr 16, 2021 at 03:16:07PM +0200, Mike Galbraith wrote:
> On Fri, 2021-04-16 at 14:16 +0200, Borislav Petkov wrote:
> >
> > Please be more verbose and structure your commit message like this:
>
> Hrmph, I thought it was too verbose for dinky one-liner if anything.
Please look at how othe
On Fri, 2021-04-16 at 14:16 +0200, Borislav Petkov wrote:
>
> Please be more verbose and structure your commit message like this:
Hrmph, I thought it was too verbose for dinky one-liner if anything. I
showed the complaint along with an 8x10 color glossy crime scene photo,
then explained why it ha
On Fri, Apr 16, 2021 at 02:02:07PM +0200, Mike Galbraith wrote:
> [ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
> crash_setup_memmap_entries+0x17e/0x3a0
> [ 15.428018] Write of size 8 at addr c9426008 by task kexec/1187
>
> (gdb) list *crash_setup_memmap_entries+0x17e
> 0x
[ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
crash_setup_memmap_entries+0x17e/0x3a0
[ 15.428018] Write of size 8 at addr c9426008 by task kexec/1187
(gdb) list *crash_setup_memmap_entries+0x17e
0x8107cafe is in crash_setup_memmap_entries
(arch/x86/kernel/crash.c:322).
31
On 04/16/21 at 01:28pm, Mike Galbraith wrote:
> On Fri, 2021-04-16 at 19:07 +0800, Dave Young wrote:
> >
> > > We're excluding two ranges, allocate the scratch space we need to do that.
> >
> > I think 1 range should be fine, have you tested 1?
>
> Have now, and vzalloc(struct_size(cmem, ranges, 1
On Fri, 2021-04-16 at 19:07 +0800, Dave Young wrote:
>
> > We're excluding two ranges, allocate the scratch space we need to do that.
>
> I think 1 range should be fine, have you tested 1?
Have now, and vzalloc(struct_size(cmem, ranges, 1)) worked just fine.
-Mike
Hi Mike,
Thanks for the patch! I suggest always cc kexec list for kexec/kdump
patches.
On 04/15/21 at 07:56pm, Mike Galbraith wrote:
> x86/crash: fix crash_setup_memmap_entries() KASAN vmalloc-out-of-bounds gripe
>
> [ 15.428011] BUG: KASAN: vmalloc-out-of-
x86/crash: fix crash_setup_memmap_entries() KASAN vmalloc-out-of-bounds gripe
[ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
crash_setup_memmap_entries+0x17e/0x3a0
[ 15.428018] Write of size 8 at addr c9426008 by task kexec/1187
(gdb) list *crash_setup_memmap_entries+0x17e
Crash shutdown handler only disables kvmclock and steal time, other PV
features remain active so we risk corrupting memory or getting some
side-effects in kdump kernel. Move crash handler to kvm.c and unify
with CPU offline.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/kvm_para.h
Dear Maintainers,
It seems we found a race condition in the aoe driver that leads to a
kernel crash. It is triggered when an aoe device is unavailable and
therefore produces an I/O error in the code that tries to remove the
device. (drivers/block/aoe/aoedev.c: aoedev_downdev)
I reproduced this
From: Tong Zhang
[ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ]
setup_fritz() in avmfritz.c might fail with -EIO and in this case the
isac.type and isac.write_reg is not initialized and remains 0(NULL).
A subsequent call to isac_release() will dereference isac->write_reg and
cr
From: Tong Zhang
[ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ]
setup_fritz() in avmfritz.c might fail with -EIO and in this case the
isac.type and isac.write_reg is not initialized and remains 0(NULL).
A subsequent call to isac_release() will dereference isac->write_reg and
cr
From: Tong Zhang
[ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ]
setup_fritz() in avmfritz.c might fail with -EIO and in this case the
isac.type and isac.write_reg is not initialized and remains 0(NULL).
A subsequent call to isac_release() will dereference isac->write_reg and
cr
From: Tong Zhang
[ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ]
setup_fritz() in avmfritz.c might fail with -EIO and in this case the
isac.type and isac.write_reg is not initialized and remains 0(NULL).
A subsequent call to isac_release() will dereference isac->write_reg and
cr
From: Tong Zhang
[ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ]
setup_fritz() in avmfritz.c might fail with -EIO and in this case the
isac.type and isac.write_reg is not initialized and remains 0(NULL).
A subsequent call to isac_release() will dereference isac->write_reg and
cr
From: Tong Zhang
[ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ]
setup_fritz() in avmfritz.c might fail with -EIO and in this case the
isac.type and isac.write_reg is not initialized and remains 0(NULL).
A subsequent call to isac_release() will dereference isac->write_reg and
cr
From: Tong Zhang
[ Upstream commit a9f81244d2e33e6dfcef120fefd30c96b3f7cdb0 ]
setup_fritz() in avmfritz.c might fail with -EIO and in this case the
isac.type and isac.write_reg is not initialized and remains 0(NULL).
A subsequent call to isac_release() will dereference isac->write_reg and
cr
"Input: gpio-keys - use hrtimer for software debounce,
> if possible")
> Reported-by: Tony Lindgren
> Signed-off-by: Dmitry Torokhov
> ---
>
> Tony, could you please try this patch and see if it fixes the crash you
> observed?
Yes great, thanks this works for me:
Tested-by: Tony Lindgren
his patch and see if it fixes the crash you
observed?
Thanks!
drivers/input/keyboard/gpio_keys.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c
b/drivers/input/keyboard/gpio_keys.c
index fe8fc76ee22e..8dbf1
, then
cfg80211_get_drvinfo will be called by below call stack, but the
wiphy->dev.parent is NULL, so kernel crash.
Call stack to cfg80211_get_drvinfo:
NetworkManager 826 [001] 6696.731371:probe:cfg80211_get_drvinfo:
(c107d8f0)
c107d8f1 cfg80211_get_drvinfo+0x1
(/lib/modules/5
, then
cfg80211_get_drvinfo will be called by below call stack, but the
wiphy->dev.parent is NULL, so kernel crash.
Call stack to cfg80211_get_drvinfo:
NetworkManager 826 [001] 6696.731371:probe:cfg80211_get_drvinfo:
(c107d8f0)
c107d8f1 cfg80211_get_drvinfo+0x1
(/lib/modules/5
From: Nick Kossifidis
This patch allows Linux to act as a crash kernel for use with
kdump. Userspace will let the crash kernel know about the
memory region it can use through linux,usable-memory property
on the /memory node (overriding its reg property), and about the
memory region where the elf
Hi Sergei!
On 4/3/21 9:48 AM, Sergei Trofimovich wrote:
> Noticed failure as a crash on ia64 when tried to symbolize all
> backtraces collected by page_owner=on:
>
> $ cat /sys/kernel/debug/page_owner
>
>
> CPU: 1 PID: 2074 Comm: cat Not tainted 5.12.0-rc4 #22
Noticed failure as a crash on ia64 when tried to symbolize all
backtraces collected by page_owner=on:
$ cat /sys/kernel/debug/page_owner
CPU: 1 PID: 2074 Comm: cat Not tainted 5.12.0-rc4 #226
Hardware name: hp server rx3600, BIOS 04.03 04/08/2008
ip is at
1 - 100 of 4539 matches
Mail list logo
