On 4/13/2021 10:01 AM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Commit 1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by
ACPI tables") attempted to address an issue with reserving the memory
occupied by ACPI tables, but it broke the initrd-based table override
mechanism re
On 3/24/2021 9:27 AM, Rafael J. Wysocki wrote:
On Wed, Mar 24, 2021 at 9:24 AM Mike Rapoport wrote:
On Tue, Mar 23, 2021 at 08:26:52PM +0100, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
The following problem has been reported by George Kennedy:
Since commit 7fef431be9c9 (&qu
On 3/24/2021 9:27 AM, Rafael J. Wysocki wrote:
On Wed, Mar 24, 2021 at 9:24 AM Mike Rapoport wrote:
On Tue, Mar 23, 2021 at 08:26:52PM +0100, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
The following problem has been reported by George Kennedy:
Since commit 7fef431be9c9 (&qu
On 3/17/2021 4:14 PM, Rafael J. Wysocki wrote:
On Monday, March 15, 2021 5:19:29 PM CET Rafael J. Wysocki wrote:
On Sun, Mar 14, 2021 at 8:00 PM Mike Rapoport wrote:
On Thu, Mar 11, 2021 at 04:36:31PM +0100, Rafael J. Wysocki wrote:
On Wed, Mar 10, 2021 at 8:47 PM David Hildenbrand wrote:
On 3/5/2021 8:40 AM, David Hildenbrand wrote:
The ibft table, for example, is mapped in via acpi_map() and kmap().
The
page for the ibft table is not reserved, so it can end up on the
freelist.
You appear to be saying that it is not sufficient to kmap() a page in
order to use it safely. It
Hello Rafael,
On 3/4/2021 7:14 AM, Rafael J. Wysocki wrote:
On Thu, Mar 4, 2021 at 2:22 AM George Kennedy wrote:
Since commit 7fef431be9c9 ("mm/page_alloc: place pages to tail
in __free_pages_core()") the following use after free occurs
intermittently when acpi tables are acce
x5af/0x66b
kernel_init+0x16/0x1d0
ret_from_fork+0x22/0x30
ACPI tables mapped via kmap() do not have their mapped pages
reserved and the pages can be "stolen" by the buddy allocator.
Use memblock_reserve() to reserve all the ACPI table pages.
Signed-off-by: George Kennedy
---
arch/x86/kerne
On 3/1/2021 9:29 AM, George Kennedy wrote:
On 2/28/2021 1:08 PM, Mike Rapoport wrote:
On Fri, Feb 26, 2021 at 11:16:06AM -0500, George Kennedy wrote:
On 2/26/2021 6:17 AM, Mike Rapoport wrote:
Hi George,
On Thu, Feb 25, 2021 at 08:19:18PM -0500, George Kennedy wrote:
Not sure if it&#
On 2/28/2021 1:08 PM, Mike Rapoport wrote:
On Fri, Feb 26, 2021 at 11:16:06AM -0500, George Kennedy wrote:
On 2/26/2021 6:17 AM, Mike Rapoport wrote:
Hi George,
On Thu, Feb 25, 2021 at 08:19:18PM -0500, George Kennedy wrote:
Not sure if it's the right thing to do, but
Hi Mike,
On 2/26/2021 6:17 AM, Mike Rapoport wrote:
Hi George,
On Thu, Feb 25, 2021 at 08:19:18PM -0500, George Kennedy wrote:
Mike,
To get rid of the 0xBE453000 hardcoding, I added the following patch
to your above patch to get the iBFT table "address" to use with
memblo
On 2/25/2021 12:33 PM, George Kennedy wrote:
On 2/25/2021 11:07 AM, Mike Rapoport wrote:
On Thu, Feb 25, 2021 at 10:22:44AM -0500, George Kennedy wrote:
On 2/24/2021 5:37 AM, Mike Rapoport wrote:
Applied just your latest patch, but same failure.
I thought there was an earlier comment
On 2/25/2021 11:07 AM, Mike Rapoport wrote:
On Thu, Feb 25, 2021 at 10:22:44AM -0500, George Kennedy wrote:
On 2/24/2021 5:37 AM, Mike Rapoport wrote:
Applied just your latest patch, but same failure.
I thought there was an earlier comment (which I can't find now) that stated
On 2/25/2021 11:07 AM, Mike Rapoport wrote:
On Thu, Feb 25, 2021 at 10:22:44AM -0500, George Kennedy wrote:
On 2/24/2021 5:37 AM, Mike Rapoport wrote:
Applied just your latest patch, but same failure.
I thought there was an earlier comment (which I can't find now) that stated
On 2/25/2021 10:22 AM, George Kennedy wrote:
On 2/25/2021 9:57 AM, Mike Rapoport wrote:
On Thu, Feb 25, 2021 at 07:38:19AM -0500, George Kennedy wrote:
On 2/25/2021 3:53 AM, Mike Rapoport wrote:
Hi George,
On 2/24/2021 5:37 AM, Mike Rapoport wrote:
On Tue, Feb 23, 2021 at 04:46:28PM
On 2/25/2021 9:57 AM, Mike Rapoport wrote:
On Thu, Feb 25, 2021 at 07:38:19AM -0500, George Kennedy wrote:
On 2/25/2021 3:53 AM, Mike Rapoport wrote:
Hi George,
On 2/24/2021 5:37 AM, Mike Rapoport wrote:
On Tue, Feb 23, 2021 at 04:46:28PM -0500, George Kennedy wrote:
Mike,
Still no
On 2/25/2021 3:53 AM, Mike Rapoport wrote:
Hi George,
On 2/24/2021 5:37 AM, Mike Rapoport wrote:
On Tue, Feb 23, 2021 at 04:46:28PM -0500, George Kennedy wrote:
Mike,
Still no luck.
[ 30.193723] iscsi: registered transport (iser)
[ 30.195970] iBFT detected.
[ 30.196571] BUG
On 2/24/2021 5:37 AM, Mike Rapoport wrote:
On Tue, Feb 23, 2021 at 04:46:28PM -0500, George Kennedy wrote:
Mike,
Still no luck.
[ 30.193723] iscsi: registered transport (iser)
[ 30.195970] iBFT detected.
[ 30.196571] BUG: unable to handle page fault for address: ff240004
Hmm
On 2/23/2021 4:32 PM, Mike Rapoport wrote:
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 7bdc0239a943..c118dd54a747 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1551,6 +1551,7 @@ void __init acpi_boot_table_init(void)
if
On 2/23/2021 3:09 PM, Mike Rapoport wrote:
On Tue, Feb 23, 2021 at 01:05:05PM -0500, George Kennedy wrote:
On 2/23/2021 10:47 AM, Mike Rapoport wrote:
It now crashes here:
[ 0.051019] ACPI: Early table checksum verification disabled
[ 0.056721] ACPI: RSDP 0xBFBFA014 24
On 2/23/2021 10:47 AM, Mike Rapoport wrote:
Hi George,
On Tue, Feb 23, 2021 at 09:35:32AM -0500, George Kennedy wrote:
On 2/23/2021 5:33 AM, Mike Rapoport wrote:
(re-added CC)
On Mon, Feb 22, 2021 at 08:24:59PM -0500, George Kennedy wrote:
On 2/22/2021 4:55 PM, Mike Rapoport wrote:
On
On 2/22/2021 11:13 AM, David Hildenbrand wrote:
On 22.02.21 16:13, George Kennedy wrote:
On 2/22/2021 4:52 AM, David Hildenbrand wrote:
On 20.02.21 00:04, George Kennedy wrote:
On 2/19/2021 11:45 AM, George Kennedy wrote:
On 2/18/2021 7:09 PM, Andrey Konovalov wrote:
On Fri, Feb 19
On 2/22/2021 4:52 AM, David Hildenbrand wrote:
On 20.02.21 00:04, George Kennedy wrote:
On 2/19/2021 11:45 AM, George Kennedy wrote:
On 2/18/2021 7:09 PM, Andrey Konovalov wrote:
On Fri, Feb 19, 2021 at 1:06 AM George Kennedy
wrote:
On 2/18/2021 3:55 AM, David Hildenbrand wrote
On 2/19/2021 11:45 AM, George Kennedy wrote:
On 2/18/2021 7:09 PM, Andrey Konovalov wrote:
On Fri, Feb 19, 2021 at 1:06 AM George Kennedy
wrote:
On 2/18/2021 3:55 AM, David Hildenbrand wrote:
On 17.02.21 21:56, Andrey Konovalov wrote:
During boot, all non-reserved memblock memory is
On 2/18/2021 7:09 PM, Andrey Konovalov wrote:
On Fri, Feb 19, 2021 at 1:06 AM George Kennedy
wrote:
On 2/18/2021 3:55 AM, David Hildenbrand wrote:
On 17.02.21 21:56, Andrey Konovalov wrote:
During boot, all non-reserved memblock memory is exposed to the buddy
allocator. Poisoning all
On 2/18/2021 3:55 AM, David Hildenbrand wrote:
On 17.02.21 21:56, Andrey Konovalov wrote:
During boot, all non-reserved memblock memory is exposed to the buddy
allocator. Poisoning all that memory with KASAN lengthens boot time,
especially on systems with large amount of RAM. This patch makes
On 2/12/2021 10:36 AM, David Hildenbrand wrote:
On 12.02.21 14:51, Dmitry Vyukov wrote:
On Fri, Feb 12, 2021 at 2:31 PM George Kennedy
wrote:
On 2/10/2021 4:51 PM, George Kennedy wrote:
On 2/3/2021 2:35 PM, Dmitry Vyukov wrote:
On Wed, Feb 3, 2021 at 8:29 PM Konrad Rzeszutek Wilk
wrote
On 2/10/2021 4:51 PM, George Kennedy wrote:
On 2/3/2021 2:35 PM, Dmitry Vyukov wrote:
On Wed, Feb 3, 2021 at 8:29 PM Konrad Rzeszutek Wilk
wrote:
Hey Dmitry, Rafael, George, please see below..
On Wed, Jan 27, 2021 at 10:10:07PM +0100, Dmitry Vyukov wrote:
On Wed, Jan 27, 2021 at 9:01
On 2/3/2021 2:35 PM, Dmitry Vyukov wrote:
On Wed, Feb 3, 2021 at 8:29 PM Konrad Rzeszutek Wilk wrote:
Hey Dmitry, Rafael, George, please see below..
On Wed, Jan 27, 2021 at 10:10:07PM +0100, Dmitry Vyukov wrote:
On Wed, Jan 27, 2021 at 9:01 PM George Kennedy
wrote:
Hi Dmitry,
On 1/27
Hi Dmitry,
On 1/27/2021 1:48 PM, Dmitry Vyukov wrote:
> On Wed, Jan 27, 2021 at 7:44 PM Konrad Rzeszutek Wilk
> wrote:
>> On Tue, Jan 26, 2021 at 01:03:21PM -0500, George Kennedy wrote:
>>> During boot of kernel with CONFIG_KASAN the following KASAN false
>>> po
complains
about this pointer with use-after-free, which this is not.
Signed-off-by: George Kennedy
---
drivers/firmware/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 5e013b6..30ddab5 100644
--- a/drivers/firmware/Makefile
-off-by: George Kennedy
Reported-by: syzbot+38a3699c7eaf165b9...@syzkaller.appspotmail.com
---
drivers/video/fbdev/core/fbcon.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index
vc_resize() can return with an error after failure. Change VT_RESIZEX ioctl
to save struct vc_data values that are modified and restore the original
values in case of error.
Signed-off-by: George Kennedy
Reported-by: syzbot+38a3699c7eaf165b9...@syzkaller.appspotmail.com
---
Version of patch
Hi Greg,
I will re-work this patch based on comments from Dan.
Thank you,
George
On 7/29/2020 8:53 AM, Greg KH wrote:
On Wed, Jul 29, 2020 at 08:39:41AM -0400, George Kennedy wrote:
Add a VT_RESIZEX check to ensure that changing the font height will not
cause a potential out-of-bounds access
Add a VT_RESIZEX check to ensure that changing the font height will not
cause a potential out-of-bounds access. The candidate font height contained
in "v_clin", though below the max, could still result in accesses beyond
the allocated font data size.
Signed-off-by: George Kennedy
R
+
On 7/26/2019 10:48 AM, George Kennedy wrote:
I have proposed "Distros and Syzkaller - Why bother?" for the LPC 2019
distros microconference.
I am curious as to how other distros are using Syzkaller and if there
are ways for us to collaborate.
I am curious how Syzkaller fit
cycle and if it is part
of the distro's Continuous Integration (CI) process?
Any insights would be appreciated.
Thank you,
George Kennedy
36 matches
Mail list logo
