Hello,
syzbot found the following issue on:
HEAD commit:82303a059aab selftests/bpf: Mitigate sockmap_ktls disconne..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=17564c7058
kernel config: https://syzkaller.appspot.com/x/.config?x=2a31f7155996562
dashboard
On Fri, Dec 20, 2024 at 9:07 AM Haichi Wang wrote:
>
> Dear Linux maintainers and reviewers:
>
> We are reporting a Linux kernel bug titled **KASAN: slab-out-of-bounds Read
> in jfs_readdir**, discovered using a modified version of Syzkaller.
>
Hello Haichi,
Unfortunately ri
Hi,
On 2024/7/13 8:44, Jakub Kicinski wrote:
> On Fri, 12 Jul 2024 17:43:21 -0700 Jakub Kicinski wrote:
>> CC: virtio_net maintainers and Jiri who added BQL
>
> Oh, sounds like the fix may be already posted:
> https://lore.kernel.org/all/20240712080329.197605-2-jean-phili...@linaro.org/
Thanks,
On Fri, 12 Jul 2024 17:43:21 -0700 Jakub Kicinski wrote:
> CC: virtio_net maintainers and Jiri who added BQL
Oh, sounds like the fix may be already posted:
https://lore.kernel.org/all/20240712080329.197605-2-jean-phili...@linaro.org/
/linux-next.git and
> the base commit is f477dd6eede3
>
> >
> > [ cut here ]
> > kernel BUG at lib/dynamic_queue_limits.c:99!
> > Oops: invalid opcode: [#1] PREEMPT SMP NOPTI
> > CPU: 1 UID: 0 PID: 203 Comm: ip Not tainted
> > 6.10.0-rc7-
d several of your others) are fixed in Linus's tree.
>
> Stack dump:
>
> bcachefs (loop1): mounting version 1.7: (unknown version)
> opts=metadata_checksum=none,data_checksum=none,nojournal_transaction_names
> ----[ cut here ]
> kernel BUG at fs/bcachefs
xdp_return_frame_no_direct() unconditionally and below false negative
kernel BUG throw happened under preempt-rt build:
[ 430.450355] BUG: using smp_processor_id() in preemptible [] code:
modprobe/3884
[ 430.451678] caller is __xdp_return+0x1ff/0x2e0
[ 430.452111] CPU: 0 PID: 3884 Comm
xdp_return_frame_no_direct() unconditionally and below false negative
kernel BUG throw happened under preempt-rt build:
[ 430.450355] BUG: using smp_processor_id() in preemptible [] code:
modprobe/3884
[ 430.451678] caller is __xdp_return+0x1ff/0x2e0
[ 430.452111] CPU: 0 PID: 3884 Comm
:
Reported-by: syzbot+5e5a981ad7cc54c4b...@syzkaller.appspotmail.com
skbuff: skb_over_panic: text:8717de50 len:692 put:3
head:888025f6f000 data:888025f6f00e tail:0x2c2 end:0x2c0 dev:bond0
[ cut here ]
kernel BUG at net/core/skbuff.c:109!
invalid opcode: [#1
page_pool memory model, __xdp_return() calls
> xdp_return_frame_no_direct() unconditionally and below false negative
> kernel BUG throw happened under preempt-rt build:
>
> [ 430.450355] BUG: using smp_processor_id() in preemptible [] code:
> modprobe/3884
> [ 430.451678] c
n() calls
> xdp_return_frame_no_direct() unconditionally and below false negative
> kernel BUG throw happened under preempt-rt build:
>
> [ 430.450355] BUG: using smp_processor_id() in preemptible [] code:
> modprobe/3884
> [ 430.451678] caller is __xdp_return+0x1ff/0x2e0
> [ 430.452111] C
xdp_return_frame() may be called outside of NAPI context to return
xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with
napi_direct = false. For page_pool memory model, __xdp_return() calls
xdp_return_frame_no_direct() unconditionally and below false negative
kernel BUG throw
>> diff --git a/net/core/xdp.c b/net/core/xdp.c
>> index 05354976c1fc..4eaa28972af2 100644
>> --- a/net/core/xdp.c
>> +++ b/net/core/xdp.c
>> @@ -350,7 +350,8 @@ static void __xdp_return(void *data, struct
>xdp_mem_info *mem, bool napi_direct,
>> /* mem->id is valid, checked in
>xdp_rx
For page_pool memory model, __xdp_return() calls
>> xdp_return_frame_no_direct() unconditionally and below false negative
>> kernel BUG throw happened under preempt-rt build:
>>
>> [ 430.450355] BUG: using smp_processor_id() in preemptible [] code:
>> modprobe/
n() calls
> xdp_return_frame_no_direct() unconditionally and below false negative
> kernel BUG throw happened under preempt-rt build:
>
> [ 430.450355] BUG: using smp_processor_id() in preemptible [] code:
> modprobe/3884
> [ 430.451678] caller is __xdp_return+0x1ff/0x2e0
> [ 430.452111] C
On Mon, Mar 29, 2021 at 10:01:58AM +0100, Luis Henriques wrote:
> On Fri, Mar 19, 2021 at 09:02:33AM +, Luis Henriques wrote:
> > On Thu, Mar 18, 2021 at 11:55:43AM +, Matthew Wilcox wrote:
> > > On Thu, Mar 18, 2021 at 11:29:28AM +, Luis Henriques wrote:
> > > > On Thu, Mar 18, 2021 at
On Fri, Mar 19, 2021 at 09:02:33AM +, Luis Henriques wrote:
> On Thu, Mar 18, 2021 at 11:55:43AM +, Matthew Wilcox wrote:
> > On Thu, Mar 18, 2021 at 11:29:28AM +, Luis Henriques wrote:
> > > On Thu, Mar 18, 2021 at 02:03:02PM +0300, Kirill A. Shutemov wrote:
> > > > On Thu, Mar 18, 202
xdp_return_frame() may be called outside of NAPI context to return
xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with
napi_direct = false. For page_pool memory model, __xdp_return() calls
xdp_return_frame_no_direct() unconditionally and below false negative
kernel BUG throw
On Thu, Mar 18, 2021 at 11:55:43AM +, Matthew Wilcox wrote:
> On Thu, Mar 18, 2021 at 11:29:28AM +, Luis Henriques wrote:
> > On Thu, Mar 18, 2021 at 02:03:02PM +0300, Kirill A. Shutemov wrote:
> > > On Thu, Mar 18, 2021 at 11:59:59AM +0100, Miklos Szeredi wrote:
> > > > > [16247.536348] pa
On Thu, Mar 18, 2021 at 11:55:43AM +, Matthew Wilcox wrote:
> On Thu, Mar 18, 2021 at 11:29:28AM +, Luis Henriques wrote:
> > On Thu, Mar 18, 2021 at 02:03:02PM +0300, Kirill A. Shutemov wrote:
> > > On Thu, Mar 18, 2021 at 11:59:59AM +0100, Miklos Szeredi wrote:
> > > > > [16247.536348] pa
On Thu, Mar 18, 2021 at 11:29:28AM +, Luis Henriques wrote:
> On Thu, Mar 18, 2021 at 02:03:02PM +0300, Kirill A. Shutemov wrote:
> > On Thu, Mar 18, 2021 at 11:59:59AM +0100, Miklos Szeredi wrote:
> > > > [16247.536348] page:dfe36ab1 refcount:673 mapcount:0
> > > > mapping:f98
This is a compound page alright. Have no idea how it got into fuse's
> > pagecache.
>
>
> Luis, do you have CONFIG_READ_ONLY_THP_FOR_FS enabled?
Yes, it looks like Tumbleweed kernels have that config option enabled by
default. And it this feature was introduced in 5.4 (
ht. Have no idea how it got into fuse's
> pagecache.
Luis, do you have CONFIG_READ_ONLY_THP_FOR_FS enabled?
> > [16247.536361] memcg:8e730012b000
> > [16247.536364] aops:fuse_file_aops [fuse] ino:8b8 dentry name:"cc1plus"
> > [16247.536379] flags:
> > 0xa800
nto fuse's
pagecache.
> [16247.536361] memcg:8e730012b000
> [16247.536364] aops:fuse_file_aops [fuse] ino:8b8 dentry name:"cc1plus"
> [16247.536379] flags:
> 0xa800010037(locked|referenced|uptodate|lru|active|head)
> [16247.536385] raw: 00a800010037 d6519ed9c448
se] ino:8b8 dentry name:"cc1plus"
[16247.536379] flags:
0xa800010037(locked|referenced|uptodate|lru|active|head)
[16247.536385] raw: 00a800010037 d6519ed9c448 d651abea5b08
8eb2f9a02ef8
[16247.536388] raw: 1400 0000 02a1
8e730012b000
[1
On Mon, Mar 15, 2021 at 1:09 PM Catalin Marinas wrote:
>
> On Mon, Mar 15, 2021 at 08:08:06AM +0100, Dmitry Vyukov wrote:
> > On Wed, Feb 3, 2021 at 6:59 AM syzbot
> > wrote:
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc
On Mon, Mar 15, 2021 at 08:08:06AM +0100, Dmitry Vyukov wrote:
> On Wed, Feb 3, 2021 at 6:59 AM syzbot
> wrote:
> > syzbot found the following issue on:
> >
> > HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc7' of g..
> > git tree: upstream
> > console output: https://syz
On Mon, Mar 15, 2021 at 09:47:45AM +, Luis Henriques wrote:
> On Fri, Mar 12, 2021 at 01:11:23PM +, Matthew Wilcox wrote:
> > On Fri, Mar 12, 2021 at 12:21:59PM +, Luis Henriques wrote:
> > > > > I've seen a bug report (5.10.16 kernel splat below) that seems to be
> > > > > reproducible
On Fri, Mar 12, 2021 at 01:11:23PM +, Matthew Wilcox wrote:
> On Fri, Mar 12, 2021 at 12:21:59PM +, Luis Henriques wrote:
> > > > I've seen a bug report (5.10.16 kernel splat below) that seems to be
> > > > reproducible in kernels as early as 5.4.
>
> If this is reproducible, can you turn
RTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+5ecbe63baca437585...@syzkaller.appspotmail.com
The BUG is:
BUG_ON(!virt_addr_valid(addr));
#syz fix: arm64: Do not pass tagged addresses to __is_lm_address()
> [ cut here ]
&
On Fri, Mar 12, 2021 at 12:21:59PM +, Luis Henriques wrote:
> > > I've seen a bug report (5.10.16 kernel splat below) that seems to be
> > > reproducible in kernels as early as 5.4.
If this is reproducible, can you turn this BUG_ON into a VM_BUG_ON_PAGE()
so we know what kind of problem we're
e
kernel with a few patches that AFAIK touch mostly drivers. But I'll see
if I can get the reporter trying to reproduce on a vanilla kernel.
Cheers,
--
Luís
>
> Thanks,
> Miklos
>
>
>
> >
> >
> > There's another splat in the bug report[1] for a 5.4.14 kernel (which may
&g
ucible on vanilla, or just openSUSE kernels?
Thanks,
Miklos
>
>
> There's another splat in the bug report[1] for a 5.4.14 kernel (which may
> be for a different bug, but the traces don't look as reliable as the one
> bellow).
>
> [1] https://bugzilla.opensuse.org/show_bug.cgi?id=
t too deeper on that -- I was wondering if you have seen something
similar before.
There's another splat in the bug report[1] for a 5.4.14 kernel (which may
be for a different bug, but the traces don't look as reliable as the one
bellow).
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=
On Mon, Mar 1, 2021 at 8:10 AM Lukas Bulwahn wrote:
>
> Hi,
>
> On Mon, Mar 1, 2021 at 7:58 AM wrote:
> >
> > This is the first time for me to report something, so maybe the format is
> > not right. Please correct me if I'm wrong. Thank you ~
> > When using Syzkaller to fuzz Linux kernel 5.11.0
Hi,
On Mon, Mar 1, 2021 at 7:58 AM wrote:
>
> This is the first time for me to report something, so maybe the format is not
> right. Please correct me if I'm wrong. Thank you ~
> When using Syzkaller to fuzz Linux kernel 5.11.0, it reported one
> null-ptr-def bug in file.c. The information is
On Fri, Feb 26, 2021 at 01:18:14PM -0800, Brad Larson wrote:
> On Fri, Feb 26, 2021 at 12:43:07PM -0800, Brad Larson wrote:
> > Kernel Oops introduced in next-20210222 due to get_max_slots return arg
> size.
> > In the function find_slots() variable max_slots is zero when
> boun
sk;
537 unsigned long max_slots = get_max_slots(boundary_mask);
Could you double-check please?
>
> [ 0.242119] kernel BUG at ./include/linux/iommu-helper.h:30!
> [0.247793] Internal error: Oops - BUG: 0 [#1] SMP
> [0.252595] Modules linked in:
> [0.255657] CPU: 0 P
Kernel Oops introduced in next-20210222 due to get_max_slots return arg size.
In the function find_slots() variable max_slots is zero when boundary_mask is
0x.
[0.242119] kernel BUG at ./include/linux/iommu-helper.h:30!
[0.247793] Internal error: Oops - BUG: 0 [#1] SMP
ent List
>
> Subject: Re: kernel BUG at mm/zswap.c:1275! (rc6 - git 61556703b610)
>
> Hello.
>
> On Thu, Feb 11, 2021 at 10:43:18AM +, Song Bao Hua (Barry Song) wrote:
> > Are you using zsmalloc? There is a known bug on the combination
> > of zsmalloc and zswa
Hello.
On Thu, Feb 11, 2021 at 10:43:18AM +, Song Bao Hua (Barry Song) wrote:
> Are you using zsmalloc? There is a known bug on the combination
> of zsmalloc and zswap, fixed by patches of tiantao:
>
> mm: set the sleep_mapped to true for zbud and z3fold
> mm/zswap: fix variable 'entry' is un
> -Original Message-
> From: Mikhail Gavrilov [mailto:mikhail.v.gavri...@gmail.com]
> Sent: Thursday, February 11, 2021 9:58 PM
> To: sjenn...@linux.vnet.ibm.com; Song Bao Hua (Barry Song)
>
> Cc: Linux List Kernel Mailing ; Linux Memory
> Management List
> S
sg*.txt
dmesg101.txt:[127850.513201] kernel BUG at mm/zswap.c:1275!
dmesg11.txt:[52211.962861] kernel BUG at mm/zswap.c:1275!
dmesg8.txt:[46610.641843] kernel BUG at mm/zswap.c:1275!
[127850.513193] [ cut here ]----
[127850.513201] kernel BUG at mm/zswap.c:1275!
[127850.513210]
:
Reported-by: syzbot+a30e620779ec2718f...@syzkaller.appspotmail.com
[ cut here ]
kernel BUG at drivers/usb/usbip/vhci_sysfs.c:396!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 9885 Comm: syz-executor837 Not tainted
5.11.0-rc6-next-20210204-syzkaller #0
Hardware name
On Tue 2021-02-02 21:59:17, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc7' of g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17ef6108d0
> kernel config: http
cbe63baca437585...@syzkaller.appspotmail.com
[ cut here ]----
kernel BUG at kernel/power/snapshot.c:257!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 2394 Comm: syz-executor.0 Not tainted
5.11.0-rc6-syzkaller-00055-g3aaf0a27ffc2 #0
Hardware name: linux,dummy-v
se: VM_BUG_ON_PAGE(!unmap_success)
[ cut here ]--------
kernel BUG at mm/huge_memory.c:2351!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 0 PID: 8483 Comm: syz-executor525 Not tainted
5.11.0-rc4-next-20210120-syzkaller #0
Hardware name: Google Google Compute Engine/Google Co
020e00 01fc 888010d0a000
page dumped because: VM_BUG_ON_PAGE(!unmap_success)
[ cut here ]--------
kernel BUG at mm/huge_memory.c:2351!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 0 PID: 8483 Comm: syz-executor525 Not tainted
5.11.0-rc4-nex
On Tue, Nov 24, 2020 at 5:14 AM Matthew Wilcox wrote:
>
> On Mon, Nov 23, 2020 at 07:42:30PM -0800, Andrew Morton wrote:
> > Matthew's series "Overhaul multi-page lookups for THP" chnages the
> > shmem code quite a bit, and in the area of truncate. Matthew, could
> > you please fire up that repro
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any
issue:
Reported-and-tested-by: syzbot+2393580080a2da190...@syzkaller.appspotmail.com
Tested on:
commit: 3a30363e net: sit: unregister_netdevice on newlink's error..
git tree: git://git.kernel.org/p
On Wed, 13 Jan 2021 02:27:27 -0800 syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:c49243e8 Merge branch 'net-fix-issues-around-register_netd..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=11da7ba8d0
> kernel config: ht
dev() more lenient with unregistering
devices")
[ cut here ]----
kernel BUG at net/core/dev.c:10661!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8459 Comm: syz-executor375 Not tainted 5.11.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compu
On Tue, Jan 12, 2021 at 2:44 AM Jan Kara wrote:
>
> On Fri 08-01-21 18:04:21, Linus Torvalds wrote:
> >
> > Oh, and Michael Larabel (of phoronix) reports that that one-liner does
> > something bad to a few PostgreSQL tests, on the order of 5-10%
> > regression on some machines (but apparently not
On Fri 08-01-21 18:04:21, Linus Torvalds wrote:
> On Tue, Jan 5, 2021 at 11:53 AM Linus Torvalds
> wrote:
> >
> > I took your "way to go" statement as an ack, and made it all be commit
> > c2407cf7d22d ("mm: make wait_on_page_writeback() wait for multiple
> > pending writebacks").
>
> Oh, and Mic
On Fri, Jan 8, 2021 at 12:40 PM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit d24396c5290ba8ab04ba505176874c4e04a2d53c
> Author: Rustam Kovhaev
> Date: Sun Nov 1 14:09:58 2020 +
>
> reiserfs: add check for an invalid ih_entry_count
>
> bisection log: http
On Sun, Jan 10, 2021 at 10:34 PM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit 537cf4e3cc2f6cc9088dcd6162de573f603adc29
> Author: Magnus Karlsson
> Date: Fri Nov 20 11:53:39 2020 +
>
> xsk: Fix umem cleanup bug at socket destruct
>
> bisection log: https:
syzbot suspects this issue was fixed by commit:
commit 537cf4e3cc2f6cc9088dcd6162de573f603adc29
Author: Magnus Karlsson
Date: Fri Nov 20 11:53:39 2020 +
xsk: Fix umem cleanup bug at socket destruct
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=139f3dfb50
start commi
On Tue, Jan 5, 2021 at 11:53 AM Linus Torvalds
wrote:
>
> I took your "way to go" statement as an ack, and made it all be commit
> c2407cf7d22d ("mm: make wait_on_page_writeback() wait for multiple
> pending writebacks").
Oh, and Michael Larabel (of phoronix) reports that that one-liner does
some
syzbot suspects this issue was fixed by commit:
commit d24396c5290ba8ab04ba505176874c4e04a2d53c
Author: Rustam Kovhaev
Date: Sun Nov 1 14:09:58 2020 +
reiserfs: add check for an invalid ih_entry_count
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1731e8f750
start co
On Tue, Jan 05, 2021 at 01:22:49PM -0800, Linus Torvalds wrote:
> On Tue, Jan 5, 2021 at 1:13 PM Hugh Dickins wrote:
> >
> > I was going to raise a question, whether you should now revert
> > 073861ed77b6 ("mm: fix VM_BUG_ON(PageTail) and BUG_ON(PageWriteback)"):
> > which would not have gone in l
On Tue, Jan 5, 2021 at 1:13 PM Hugh Dickins wrote:
>
> I was going to raise a question, whether you should now revert
> 073861ed77b6 ("mm: fix VM_BUG_ON(PageTail) and BUG_ON(PageWriteback)"):
> which would not have gone in like that if c2407cf7d22d were already in.
Honestly, even if it wasn't for
On Tue, 5 Jan 2021, Linus Torvalds wrote:
> On Tue, Jan 5, 2021 at 11:31 AM Linus Torvalds
> wrote:
> > On Mon, Jan 4, 2021 at 7:29 PM Hugh Dickins wrote:
> > >
> > > > So the one-liner of changing the "if" to "while" in
> > > > wait_on_page_writeback() should get us back to what we used to do.
>
On Tue, Jan 5, 2021 at 11:31 AM Linus Torvalds
wrote:
>
> On Mon, Jan 4, 2021 at 7:29 PM Hugh Dickins wrote:
> >
> > > So the one-liner of changing the "if" to "while" in
> > > wait_on_page_writeback() should get us back to what we used to do.
> >
> > I think that is the realistic way to go.
>
>
On Mon, Jan 4, 2021 at 7:29 PM Hugh Dickins wrote:
>
> > But I feel it's really that end_page_writeback() itself is
> > fundamentally buggy, because the "wakeup" is not atomic with the bit
> > clearing _and_ it doesn't actually hold the page lock that is
> > allegedly serializing this all.
>
> And
947dd3e8c72dbe6...@syzkaller.appspotmail.com
[ cut here ]----
kernel BUG at fs/ext4/ext4.h:3221!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 12285 Comm: syz-executor.5 Not tainted 5.11.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engi
On Mon, 4 Jan 2021, Linus Torvalds wrote:
> On Mon, Jan 4, 2021 at 12:41 PM Andrew Morton
> wrote:
>
> > Linus, how confident are you in those wait_on_page_bit_common()
> > changes?
>
> Pretty confident. The atomicity of the bitops themselves is fairly simple.
>
> But in the writeback bit? No.
On Mon, Jan 4, 2021 at 12:41 PM Andrew Morton wrote:
>
> >
> > kernel BUG at mm/page-writeback.c:2241!
> > Call Trace:
> > mpage_writepages+0xd8/0x230 fs/mpage.c:714
> > do_writepages+0xec/0x290 mm/page-writeback.c:2352
> > __filemap_fdataw
t.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+2fc0712f8f8b8b8fa...@syzkaller.appspotmail.com
>
> kernel BUG at mm/page-writeback.c:2241!
> invalid opcode: [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 26311 Comm: syz-execu
c0712f8f8b8b8fa...@syzkaller.appspotmail.com
kernel BUG at mm/page-writeback.c:2241!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 26311 Comm: syz-executor.2 Not tainted 5.11.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:wr
constant arguments")
> >
> > That looks unlikely, although possibly some constant folding
> > improvement might make the fortify code notice something with it.
> >
> > > detected buffer overflow in strlen
> > > [ cut here ]
ding
> improvement might make the fortify code notice something with it.
>
> > detected buffer overflow in strlen
> > [ cut here ]
> > kernel BUG at lib/string.c:1149!
> > Call Trace:
> > strlen include/linux/string.h:325 [inline]
> > s
it.
> detected buffer overflow in strlen
> ----[ cut here ]
> kernel BUG at lib/string.c:1149!
> Call Trace:
> strlen include/linux/string.h:325 [inline]
> strlcpy include/linux/string.h:348 [inline]
> xt_rateest_tg_checkentry+0x2a5/0x6b0 net/netfilter/
bris...@redhat.com; x...@kernel.org; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-hyp...@vger.kernel.org; Michael Kelley
>
> Subject: Re: v5.10: sched_cpu_dying() hits BUG_ON during hibernation: kernel
> BUG at kernel/sched/core.c:7596!
>
>
> Hi,
>
stant arguments")
detected buffer overflow in strlen
[ cut here ]----
kernel BUG at lib/string.c:1149!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 0 PID: 8713 Comm: syz-executor731 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Eng
Hi,
On 22/12/20 09:13, Dexuan Cui wrote:
> Hi,
> I'm running a Linux VM with the recent mainline (48342fc07272, 12/20/2020) on
> Hyper-V.
> When I test hibernation, the VM can easily hit the below BUG_ON during the
> resume
> procedure (I estimate this can repro about 1/5 of the time). BTW, my
is now offline
[ 11.771224] smpboot: CPU 37 is now offline
[ 11.795089] [ cut here ]----
[ 11.798052] kernel BUG at kernel/sched/core.c:7596!
[ 11.798052] invalid opcode: [#1] PREEMPT SMP PTI
[ 11.798052] CPU: 38 PID: 202 Comm: migration/38 Tainted: G
On Sat, Dec 19, 2020 at 3:50 AM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit e722a295cf493388dae474745d30e91e1a2ec549
> Author: Greg Kroah-Hartman
> Date: Thu Aug 27 12:36:27 2020 +
>
> staging: ion: remove from the tree
>
> bisection log: https://syzkal
syzbot suspects this issue was fixed by commit:
commit e722a295cf493388dae474745d30e91e1a2ec549
Author: Greg Kroah-Hartman
Date: Thu Aug 27 12:36:27 2020 +
staging: ion: remove from the tree
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17d4f13750
start commit: ab
On Wed 09-12-20 17:15:02, Miklos Szeredi wrote:
> On Wed, Dec 9, 2020 at 2:59 PM Jan Kara wrote:
> >
> > On Wed 09-12-20 14:38:42, Jan Kara wrote:
> > > Hello!
> > >
> > > so I was debugging the dnotify crash below (it's 100% reproducible for me)
> > > and I came to the following. The reproducer o
On Wed, Dec 9, 2020 at 2:59 PM Jan Kara wrote:
>
> On Wed 09-12-20 14:38:42, Jan Kara wrote:
> > Hello!
> >
> > so I was debugging the dnotify crash below (it's 100% reproducible for me)
> > and I came to the following. The reproducer opens 'file0' on FUSE
> > filesystem which is a directory at th
657052550
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=1557052550
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1157052550
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-
...@syzkaller.appspotmail.com
>
> wlan1: Creating new IBSS network, BSSID 50:50:50:50:50:50
> [ cut here ]
> kernel BUG at fs/notify/dnotify/dnotify.c:118!
> invalid opcode: [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 648 Comm: kworker/u4:4 Not tainted 5.10.0-rc4-
1bcf66d5e11d021...@syzkaller.appspotmail.com
[ cut here ]----
kernel BUG at mm/internal.h:400!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 0 PID: 28126 Comm: kworker/u4:0 Not tainted 5.10.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
ea000448 ea000448
raw:
page dumped because: VM_BUG_ON_PAGE(pfn & ((1 << order) - 1))
[ cut here ]--------
kernel BUG at mm/page_alloc.c:1015!
invalid opcode: [#1] PREEMPT SMP KA
On Thu, 3 Dec 2020 at 12:24, Mike Rapoport wrote:
> Yeah, the change to initialization of "unavailable" memory missed pfn 0 :(
> This should fix it:
Tried locally and it fixes the issue for me :)
> page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page))
> [ cut here ]
> kernel BUG at include/linux/page-flags.h:356!
Yeah, the change to initialization of "unavailable" memory missed pfn 0 :(
This should fix it:
>From 84a1c2531374706f35
ea08
raw:
page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page))
[ cut here ]----
kernel BUG at include/linux/page-flags.h:356!
invalid opcode: [#1] PREEMPT SMP KASA
Hi Andreas,
On Tue, Dec 1, 2020 at 11:44 AM Andreas Kemnade wrote:
>
> So if that one is really active-low, why did it ever work?!
Because the spi gpio chipselect was broken (inverted), and
766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
fixes it.
> Am 01.12.2020 um 17:44 schrieb Andreas Kemnade :
>
> On Tue, 1 Dec 2020 11:10:49 -0500
> Sven Van Asbroeck wrote:
>
>> Nikolaus,
>>
>> On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller
>> wrote:
>>>
>>> Let's work on a fix for the fix now.
>>>
>>
>> Are you quite sure the chip-select
> Am 01.12.2020 um 17:44 schrieb Andreas Kemnade :
>
> On Tue, 1 Dec 2020 11:10:49 -0500
> Sven Van Asbroeck wrote:
>
>> Nikolaus,
>>
>> On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller
>> wrote:
>>>
>>> Let's work on a fix for the fix now.
>>>
>>
>> Are you quite sure the chip-select
On Tue, 1 Dec 2020 11:10:49 -0500
Sven Van Asbroeck wrote:
> Nikolaus,
>
> On Tue, Dec 1, 2020 at 9:38 AM H. Nikolaus Schaller
> wrote:
> >
> > Let's work on a fix for the fix now.
> >
>
> Are you quite sure the chip-select of the tpo,td028ttec1 panel
> is active-high? A quick google produc
On Wed, Nov 25, 2020 at 1:30 PM Linus Torvalds
wrote:
>
> I'm not sure I'm willing to write and test the real patch, but it
> doesn't look _too_ nasty from just looking at the code. The bookmark
> thing makes it important to only actually clear the bit at the end (as
> does the handoff case anyway
On Tue, Nov 24, 2020 at 3:24 PM Linus Torvalds
wrote:
>
> I've applied your second patch (the smaller one that just takes a ref
> around the critical section). If somebody comes up with some great
> alternative, we can always revisit this.
Hmm.
I'm not sure about "great alternative", but it stri
On 2020-11-25 00:46:32 [+], Matthew Wilcox wrote:
>
> Thanks for debugging this! I didn't realise start1 was allowed to be
> less than start2. Try this ... (systemd is sabotaging my efforts to
> test an i386 kernel)
You are welcome.
Reviewed-by: Sebastian Andrzej Siewior
Sebastian
On Wed, 25 Nov 2020 at 06:16, Matthew Wilcox wrote:
>
> On Tue, Nov 24, 2020 at 06:16:28PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2020-11-24 18:52:44 [+0530], Naresh Kamboju wrote:
> > > While running LTP test case access01 the following kernel BUG
> > > noti
On Tue 24-11-20 12:19:12, Matthew Wilcox wrote:
> On Mon, Nov 23, 2020 at 08:07:24PM -0800, Hugh Dickins wrote:
> > Twice now, when exercising ext4 looped on shmem huge pages, I have crashed
> > on the PF_ONLY_HEAD check inside PageWaiters(): ext4_finish_bio() calling
> > end_page_writeback() calli
On Tue, Nov 24, 2020 at 06:16:28PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-24 18:52:44 [+0530], Naresh Kamboju wrote:
> > While running LTP test case access01 the following kernel BUG
> > noticed on linux next 20201124 tag kernel on i386.
> &g
On Tue, Nov 24, 2020 at 1:47 PM Hugh Dickins wrote:
>
> I think the unreferenced struct page asks for trouble.
I do agree.
I've applied your second patch (the smaller one that just takes a ref
around the critical section). If somebody comes up with some great
alternative, we can always revisit t
On Tue, 24 Nov 2020, Linus Torvalds wrote:
> On Tue, Nov 24, 2020 at 12:16 PM Matthew Wilcox wrote:
> >
> > So my s/if/while/ suggestion is wrong and we need to do something to
> > prevent spurious wakeups. Unless we bury the spurious wakeup logic
> > inside wait_on_page_writeback() ...
>
> We c
On Tue, Nov 24, 2020 at 12:16 PM Matthew Wilcox wrote:
>
> So my s/if/while/ suggestion is wrong and we need to do something to
> prevent spurious wakeups. Unless we bury the spurious wakeup logic
> inside wait_on_page_writeback() ...
We can certainly make the "if()" in that loop be a "while()'.
1 - 100 of 2189 matches
Mail list logo
