Hi,
I attached the vmcore with vmlinux symbol for further analysis and will share
it at the following link.
Link:
https://drive.google.com/file/d/1_RFdpdWNuLdO-Yx6d7vIX-WAFX4X_msH/view?usp=drive_link
On 5/6/25 9:30 오전, Yunseong Kim wrote:
> Hi Colin,
>
>>> The crash seems to originate from rc
On 3/26/25 13:25, David Binderman wrote:
Hello there,
Static analyser cppcheck says:
linux-6.14/tools/testing/selftests/mm/pagemap_ioctl.c:1061:11: style: int
result is assigned to long long variable. If the variable is long long to avoid
loss of information, then you have loss of informatio
On 10/21/24 2:33 AM, David Hildenbrand wrote:
Am 21.10.24 um 08:48 schrieb Muhammad Usama Anjum:
...
But now comes the tricky part: an architecture defines whether it wants to
(a) Use the asm-generic unistd.h
(b) Use a custom one
E.g.,
$ cat include/uapi/linux/unistd.h
/* SPDX-License-Identi
Am 21.10.24 um 08:48 schrieb Muhammad Usama Anjum:
Hi,
The asm-generic/unistd.h file has wrong __NR_userfaultfd syscall number which
doesn't even depend on the architecture. This has caused failure of a selftest
which was fixed recently [1].
grep -rnIF "#define __NR_userfaultfd"
tools/includ
On 9/20/24 18:22, Mirsad Todorovac wrote:
> Hi, all,
>
> I was testing Linux torvalds tree vanilla kernel, and I've noticed for a
> number of releases this
> ./nci_dev stops testing until it's terminated (15).
>
> Now, I tried to examine what went wrong, I hoped it will go away by itself.
> it
> After several tests, I found that the same PoC can cause multiple
> different crashes for some unknown reason. Thus, I suspect that the
> bug is capable of performing unintended memory writing without being
> caught by KASAN.
> I tested the PoC on the latest kernel, Linux 6.11 rc7 and it can stil
After several tests, I found that the same PoC can cause multiple
different crashes for some unknown reason. Thus, I suspect that the
bug is capable of performing unintended memory writing without being
caught by KASAN.
I tested the PoC on the latest kernel, Linux 6.11 rc7 and it can still
cause cr
Juefei will answer this. I already Cc'd him.
On Thu, Sep 12, 2024 at 9:08 AM Uladzislau Rezki wrote:
>
> > > >
> > > > Here is the config file:
> > > > https://gist.github.com/TomAPU/64f5db0fe976a3e94a6dd2b621887cdd
> > > >
> I tested your "reproducer" on 6.11.0-rc2. I see some panics and they a
> > >
> > > Here is the config file:
> > > https://gist.github.com/TomAPU/64f5db0fe976a3e94a6dd2b621887cdd
> > >
I tested your "reproducer" on 6.11.0-rc2. I see some panics and they are
different. For example below one triggers: BUG: kernel NULL pointer
dereference, address: 0010
Lin
Here is to set up the reproducing environment:
https://github.com/TomAPU/Linux610BugReort
We tested it, and it can reproduce.
On Wed, Sep 4, 2024 at 10:52 AM Uladzislau Rezki wrote:
>
> Hello!
>
> >
> > Here is the config file:
> > https://gist.github.com/TomAPU/64f5db0fe976a3e94a6dd2b621887cdd
>
Hello!
>
> Here is the config file:
> https://gist.github.com/TomAPU/64f5db0fe976a3e94a6dd2b621887cdd
>
Thank you. I was not able to boot my box using your config file. But i
enabled all needed configs in to run your reproduce so it does not
complain on below warnings:
urezki@pc638:~$ sudo ./a.
On Wed, 21 Aug 2024 11:50:00 -0400
Steven Rostedt wrote:
> On Wed, 21 Aug 2024 16:42:07 +0100
> Mark Rutland wrote:
>
> > FWIW, that was in samples/ftrace/ftrace-ops.c, where tracee_relevant() and
> > tracee_irrelevant() have the barrier():
> >
> > | /*
> > | * Marked as noinline to ensure th
On Wed, 21 Aug 2024 16:42:07 +0100
Mark Rutland wrote:
> FWIW, that was in samples/ftrace/ftrace-ops.c, where tracee_relevant() and
> tracee_irrelevant() have the barrier():
>
> | /*
> | * Marked as noinline to ensure that an out-of-line traceable copy is
> | * generated by the compiler.
> |
On Wed, Aug 21, 2024 at 04:32:46PM +0100, Mark Rutland wrote:
> On Wed, Aug 21, 2024 at 07:05:39AM +0900, Masami Hiramatsu wrote:
> > On Tue, 20 Aug 2024 08:10:42 -0700
> > Sami Tolvanen wrote:
> >
> > > On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> > > >
> > > > On Tue, Aug 20, 2024 at
On Wed, Aug 21, 2024 at 07:05:39AM +0900, Masami Hiramatsu wrote:
> On Tue, 20 Aug 2024 08:10:42 -0700
> Sami Tolvanen wrote:
>
> > On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> > >
> > > On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> > > > On Mon, 19 Aug 2024 12:02:
On Tue, Aug 20, 2024 at 5:21 PM Masami Hiramatsu wrote:
>
> On Wed, 21 Aug 2024 08:43:51 +0900
> Masami Hiramatsu (Google) wrote:
>
> > On Tue, 20 Aug 2024 18:11:09 -0400
> > Steven Rostedt wrote:
> >
> > > On Wed, 21 Aug 2024 07:05:39 +0900
> > > Masami Hiramatsu (Google) wrote:
> > >
> > >
>
On Wed, 21 Aug 2024 08:43:51 +0900
Masami Hiramatsu (Google) wrote:
> On Tue, 20 Aug 2024 18:11:09 -0400
> Steven Rostedt wrote:
>
> > On Wed, 21 Aug 2024 07:05:39 +0900
> > Masami Hiramatsu (Google) wrote:
> >
> >
> > > Does the noinline attribute prevent embedding callsite too? I mean
> >
On Tue, 20 Aug 2024 19:49:14 -0400
Steven Rostedt wrote:
> On Wed, 21 Aug 2024 08:43:51 +0900
> Masami Hiramatsu (Google) wrote:
>
> > > Can you add the __used and see if it fixes it?
> >
> > Adding __used to DYN_FTRACE_TEST_NAME() and DYN_FTRACE_TEST_NAME2() does
> > not change, the test st
On Wed, 21 Aug 2024 08:43:51 +0900
Masami Hiramatsu (Google) wrote:
> > Can you add the __used and see if it fixes it?
>
> Adding __used to DYN_FTRACE_TEST_NAME() and DYN_FTRACE_TEST_NAME2() does
> not change, the test still fails.
OK, now that sounds like a bug in LTO itself.
-- Steve
On Tue, 20 Aug 2024 18:11:09 -0400
Steven Rostedt wrote:
> On Wed, 21 Aug 2024 07:05:39 +0900
> Masami Hiramatsu (Google) wrote:
>
>
> > Does the noinline attribute prevent embedding callsite too? I mean
> >
> > extern callee()
> >
> > noinline callee()
> > {
> > ...
> > }
> >
> > caller()
On Wed, 21 Aug 2024 07:05:39 +0900
Masami Hiramatsu (Google) wrote:
> Does the noinline attribute prevent embedding callsite too? I mean
>
> extern callee()
>
> noinline callee()
> {
> ...
> }
>
> caller()
> {
> callee() // (*)
> }
>
> In this case, does noinline prevent LTO to embed t
On Tue, 20 Aug 2024 08:10:42 -0700
Sami Tolvanen wrote:
> On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> >
> > On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> > > On Mon, 19 Aug 2024 12:02:44 -0400
> > > Steven Rostedt wrote:
> > >
> > > > On Tue, 20 Aug 2024 00:56:49
On Tue, 20 Aug 2024 08:10:42 -0700
Sami Tolvanen wrote:
> On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> >
> > On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> > > On Mon, 19 Aug 2024 12:02:44 -0400
> > > Steven Rostedt wrote:
> > >
> > > > On Tue, 20 Aug 2024 00:5
On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
>
> On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> > On Mon, 19 Aug 2024 12:02:44 -0400
> > Steven Rostedt wrote:
> >
> > > On Tue, 20 Aug 2024 00:56:49 +0900
> > > Masami Hiramatsu (Google) wrote:
> > > >
> > > > >
> > > >
On Tue, 20 Aug 2024 11:48:07 +0100
Mark Rutland wrote:
> > I found the target function already has "noinline". I tried to add noinline
> > to the testing function (callsite), but it also did not work.
> > I think "noinline" is for the compiler, but LTO is done by the linker.
>
> If LTO is brea
On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> On Mon, 19 Aug 2024 12:02:44 -0400
> Steven Rostedt wrote:
>
> > On Tue, 20 Aug 2024 00:56:49 +0900
> > Masami Hiramatsu (Google) wrote:
> > >
> > > >
> > > > We may need to add "noinline" or something to make sure those funct
On Mon, 19 Aug 2024 12:02:44 -0400
Steven Rostedt wrote:
> On Tue, 20 Aug 2024 00:56:49 +0900
> Masami Hiramatsu (Google) wrote:
> >
> > >
> > > We may need to add "noinline" or something to make sure those functions
> > > don't get inlined for LTO.
> >
> > Yeah, we need such option at leas
On Mon, 19 Aug 2024 12:02:44 -0400
Steven Rostedt wrote:
> On Tue, 20 Aug 2024 00:56:49 +0900
> Masami Hiramatsu (Google) wrote:
> >
> > >
> > > We may need to add "noinline" or something to make sure those functions
> > > don't get inlined for LTO.
> >
> > Yeah, we need such option at leas
On Tue, 20 Aug 2024 00:56:49 +0900
Masami Hiramatsu (Google) wrote:
>
> >
> > We may need to add "noinline" or something to make sure those functions
> > don't get inlined for LTO.
>
> Yeah, we need such option at least for function call test.
Could you add the noinline, and if it fixes the
On Mon, 19 Aug 2024 11:29:02 -0400
Steven Rostedt wrote:
> On Mon, 19 Aug 2024 17:11:52 +0900
> Masami Hiramatsu (Google) wrote:
>
> > CONFIG_LTO=y
> > CONFIG_LTO_CLANG=y
>
> Hi Masami,
>
> Does it still fail if you disable the above?
No, I found that caused these failure.
> I wonder if tha
On Mon, 19 Aug 2024 17:11:52 +0900
Masami Hiramatsu (Google) wrote:
> CONFIG_LTO=y
> CONFIG_LTO_CLANG=y
Hi Masami,
Does it still fail if you disable the above?
I wonder if that causes functions to not be part of the available filter
functions that the ftrace filter test is using :-/
We may ne
Hi,
On Mon, Aug 05, 2024 at 08:44:11AM GMT, Ubisectech Sirius wrote:
Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel 6.8. Attached to the
email were a PoC file of the issue.
Thanks for the report!
It
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/
CC: virtio_net maintainers and Jiri who added BQL
On Fri, 12 Jul 2024 10:12:42 +0800 xiujianfeng wrote:
> On 2024/7/12 10:08, xiujianfeng wrote:
> > I found a problem with my QEMU environment, and the log is as follows.
> >
> > After I did the bisect to locate the issue, I found
> > 8490dd0592e85
disabled CONFIG_FORCE_NR_CPUS option for 6.9.5 but the trace + panic
still exists. So that one didn't help. I've also been bisecting the
trace but have not finished it yet as the last half dozen builds
produced non-bootable kernels. Anyway, I will continue it soon(ish)
when I have a bit more free
On Thu, 13 Jun 2024 10:32:24 +0300
Ilkka Naulapää wrote:
> ok, so if you don't have any idea where this bug is after those debug
> patches, I'll try to find some time to bisect it as a last resort.
> Stay tuned.
FYI,
I just debugged a strange crash that was caused by my config having
something
On 13.06.24 09:32, Ilkka Naulapää wrote:
> On Wed, Jun 12, 2024 at 6:56 PM Steven Rostedt wrote:
>> On Wed, 12 Jun 2024 15:36:22 +0200
>> "Linux regression tracking (Thorsten Leemhuis)"
>> wrote:
>>>
>>> Ilkka or Steven, what happened to this? This thread looks stalled. I
>>> also was unsuccessf
ok, so if you don't have any idea where this bug is after those debug
patches, I'll try to find some time to bisect it as a last resort.
Stay tuned.
--Ilkka
On Wed, Jun 12, 2024 at 6:56 PM Steven Rostedt wrote:
>
> On Wed, 12 Jun 2024 15:36:22 +0200
> "Linux regression tracking (Thorsten Leemhui
On Wed, 12 Jun 2024 15:36:22 +0200
"Linux regression tracking (Thorsten Leemhuis)"
wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
>
> Ilkka or Steven, what happened to this? This thread looks stalled. I
> al
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
Ilkka or Steven, what happened to this? This thread looks stalled. I
also was unsuccessful when looking for other threads related to this
report or the culprit. Did it fall t
On Thu, 30 May 2024 16:02:37 +0300
Ilkka Naulapää wrote:
> applied your patch and here's the output.
>
Unfortunately, it doesn't give me any new information. I added one more
BUG on, want to try this? Otherwise, I'm pretty much at a lost. :-/
-- Steve
diff --git a/fs/tracefs/inode.c b/fs/trac
On Wed, 29 May 2024 14:47:57 -0400
Steven Rostedt wrote:
> Let me make a debug patch (that crashes on this issue) for that kernel,
> and perhaps you could bisect it?
Can you try this on 6.6-rc1 and see if it gives you any other splats?
Hmm, you can switch it to WARN_ON and that way it may not c
On Wed, 29 May 2024 21:36:08 +0300
Ilkka Naulapää wrote:
> applied your patch without others, so trace and panic there.
> Screenshot attached. Also tested kernels backward and found out that
Bah, it's still in an RCU callback, which doesn't tell us why a
normal inode is being sent to the trace i
On Tue, 28 May 2024 07:51:30 +0300
Ilkka Naulapää wrote:
> yeah, the cache_from_obj tracing bug (without panic) has been
> displayed quite some time now - maybe even since 6.7.x or so. I could
> try checking a few versions back for this and try bisecting it if I
> can find when this started.
>
yeah, the cache_from_obj tracing bug (without panic) has been
displayed quite some time now - maybe even since 6.7.x or so. I could
try checking a few versions back for this and try bisecting it if I
can find when this started.
--Ilkka
On Tue, May 28, 2024 at 1:31 AM Steven Rostedt wrote:
>
> On
I tried 6.10-rc1 and it still ends up to panic
--Ilkka
On Tue, May 28, 2024 at 12:44 AM Steven Rostedt wrote:
>
> On Mon, 27 May 2024 20:14:42 +0200
> Greg KH wrote:
>
> > On Mon, May 27, 2024 at 07:40:21PM +0300, Ilkka Naulapää wrote:
> > > Hi Steven,
> > >
> > > I took some time and bisected
On Fri, 24 May 2024 12:50:08 +0200
"Linux regression tracking (Thorsten Leemhuis)"
wrote:
> > - Affected Versions: Before kernel version 6.8.10, the bug caused a
> > quick display of a kernel trace dump before the shutdown/reboot
> > completed. Starting from version 6.8.10 and continuing into ve
On Mon, 27 May 2024 20:14:42 +0200
Greg KH wrote:
> On Mon, May 27, 2024 at 07:40:21PM +0300, Ilkka Naulapää wrote:
> > Hi Steven,
> >
> > I took some time and bisected the 6.8.9 - 6.8.10 and git gave the
> > panic inducing commit:
> >
> > 414fb08628143 (tracefs: Reset permissions on remount if
On Mon, May 27, 2024 at 07:40:21PM +0300, Ilkka Naulapää wrote:
> Hi Steven,
>
> I took some time and bisected the 6.8.9 - 6.8.10 and git gave the
> panic inducing commit:
>
> 414fb08628143 (tracefs: Reset permissions on remount if permissions are
> options)
>
> I reverted that commit to 6.9.2
Hi Steven,
I took some time and bisected the 6.8.9 - 6.8.10 and git gave the
panic inducing commit:
414fb08628143 (tracefs: Reset permissions on remount if permissions are options)
I reverted that commit to 6.9.2 and now it only serves the trace but
the panic is gone. But I can live with it.
--
On Fri, 24 May 2024 12:50:08 +0200
"Linux regression tracking (Thorsten Leemhuis)"
wrote:
> > - Affected Versions: Before kernel version 6.8.10, the bug caused a
> > quick display of a kernel trace dump before the shutdown/reboot
> > completed. Starting from version 6.8.10 and continuing into ve
On Fri, 24 May 2024 12:50:08 +0200
"Linux regression tracking (Thorsten Leemhuis)"
wrote:
> [CCing a few people]
>
Thanks for the Cc.
> On 24.05.24 12:31, Ilkka Naulapää wrote:
> >
> > I have encountered a critical bug in the Linux vanilla kernel that
> > leads to a kernel panic during the s
[CCing a few people]
On 24.05.24 12:31, Ilkka Naulapää wrote:
>
> I have encountered a critical bug in the Linux vanilla kernel that
> leads to a kernel panic during the shutdown or reboot process. The
> issue arises after all services, including `journald`, have been
> stopped. As a result, the
On Tue, 02 Jan 2024 18:54:26 +0800
"Ubisectech Sirius" wrote:
> Dear concerned.
> Greetings!
> We are Ubisectech Sirius Team, the vulnerability lab of China
> ValiantSec.Recently, our team has discovered a issue in Linux kernel 6.7.
> technical details:
> 1. Vulnerability Description: BUG: unabl
Hi,
On 12/21/2023 1:50 AM, Yonghong Song wrote:
>
> On 12/20/23 1:19 AM, Hou Tao wrote:
>> Hi,
>>
>> On 12/14/2023 11:40 AM, xingwei lee wrote:
>>> Hello I found a bug in net/bpf in the lastest upstream linux and
>>> comfired in the lastest net tree and lastest net bpf titled BUG:
>>> unable to ha
On 12/20/23 1:19 AM, Hou Tao wrote:
Hi,
On 12/14/2023 11:40 AM, xingwei lee wrote:
Hello I found a bug in net/bpf in the lastest upstream linux and
comfired in the lastest net tree and lastest net bpf titled BUG:
unable to handle kernel paging request in bpf_probe_read_compat_str
If you fix
Hi,
On 12/14/2023 11:40 AM, xingwei lee wrote:
> Hello I found a bug in net/bpf in the lastest upstream linux and
> comfired in the lastest net tree and lastest net bpf titled BUG:
> unable to handle kernel paging request in bpf_probe_read_compat_str
>
> If you fix this issue, please add the follo
19.04.2021 13:07, Linus Walleij пишет:
> On Mon, Apr 19, 2021 at 8:06 AM Dmitry Osipenko wrote:
>
>> The driver uses
>> (x+23000)/280 formula for the conversion of raw temperature value, which
>> gives 82C for x=0, thus apparently formula is wrong because x=5
>> should give us ~25C.
>>
>> I t
On Wed, 14 Apr 2021 at 11:48, Christian König
wrote:
>
> >> commit f63da9ae7584280582cbc834b20cc18bfb203b14
> >> Author: Philip Yang
> >> Date: Thu Apr 1 00:22:23 2021 -0400
> >>
> >> drm/amdgpu: reserve fence slot to update page table
> >>
>
> That is expected behavior, the application i
On Tue, 20 Apr 2021 at 19:47, Eric Dumazet wrote:
>
> On Tue, Apr 20, 2021 at 3:45 PM Naresh Kamboju
> wrote:
> >
> > Following kernel BUG reported on qemu-arm64 running linux next 20210420
> > the config is enabled with KASAN.
> >
> > steps to reproduce:
> >
> > - Bu
On Tue, Apr 20, 2021 at 3:45 PM Naresh Kamboju
wrote:
>
> Following kernel BUG reported on qemu-arm64 running linux next 20210420
> the config is enabled with KASAN.
>
> steps to reproduce:
>
> - Build the arm64 kernel with KASAN enabled.
> - boot it with below command
On Mon, Apr 19, 2021 at 8:06 AM Dmitry Osipenko wrote:
> The driver uses
> (x+23000)/280 formula for the conversion of raw temperature value, which
> gives 82C for x=0, thus apparently formula is wrong because x=5
> should give us ~25C.
>
> I tried to search for the datasheet with the formula
Hi,
On Wed, 14 Apr 2021, Salvatore Bonaccorso
wrote:
Hi Ioan-Adrian,
On Wed, Apr 07, 2021 at 02:47:24PM +0200, Alessandro Grassi
wrote:
Source: linux Severity: normal Tags: upstream X-Debbugs-Cc:
alessan...@aggro.it Greetings, I am encountering the issue
described in this thread[1], usi
Hi Ioan-Adrian,
On Wed, Apr 07, 2021 at 02:47:24PM +0200, Alessandro Grassi wrote:
> Source: linux
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: alessan...@aggro.it
>
> Greetings,
>
> I am encountering the issue described in this thread[1], using a gamepad
> identified as "DragonRise" wit
Am 13.04.21 um 23:19 schrieb Mikhail Gavrilov:
On Tue, 13 Apr 2021 at 12:29, Christian König wrote:
Hi Mikhail,
the crash is a known issue and should be fixed by:
commit f63da9ae7584280582cbc834b20cc18bfb203b14
Author: Philip Yang
Date: Thu Apr 1 00:22:23 2021 -0400
drm/amdgpu: r
On 4/13/21 11:07 PM, Heiner Kallweit wrote:
On 13.04.2021 22:59, Xose Vazquez Perez wrote:
A non-recurring bug, on 5.11.12-300.fc34.x86_64 (Fedora kernel).
Thanks.
0c:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
On Tue, 13 Apr 2021 at 12:29, Christian König wrote:
>
> Hi Mikhail,
>
> the crash is a known issue and should be fixed by:
>
> commit f63da9ae7584280582cbc834b20cc18bfb203b14
> Author: Philip Yang
> Date: Thu Apr 1 00:22:23 2021 -0400
>
> drm/amdgpu: reserve fence slot to update page tabl
On 13.04.2021 22:59, Xose Vazquez Perez wrote:
> A non-recurring bug, on 5.11.12-300.fc34.x86_64 (Fedora kernel).
>
> Thanks.
>
>
> 0c:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
>
> [ 2.96
Hi Mikhail,
the crash is a known issue and should be fixed by:
commit f63da9ae7584280582cbc834b20cc18bfb203b14
Author: Philip Yang
Date: Thu Apr 1 00:22:23 2021 -0400
drm/amdgpu: reserve fence slot to update page table
But that an userspace application can cause a page fault is perfectl
On Mon, Apr 12, 2021 at 12:11 AM Hao Sun wrote:
>
> Besides, another similar bug occurred while fault injection was enabled.
>
> BUG: unable to handle kernel paging request in bpf_prog_alloc_no_stats
>
> RAX: ffda RBX: 0
Besides, another similar bug occurred while fault injection was enabled.
BUG: unable to handle kernel paging request in bpf_prog_alloc_no_stats
RAX: ffda RBX: 0059c080 RCX: 0047338d
RDX: 0078 RSI:
On Sun, Apr 11, 2021 at 9:31 PM Hao Sun wrote:
>
> Hi
>
> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> the Linux kernel, I found the following bug report, but I'm not sure
> about this.
> Sorry, I do not have a reproducing program for this bug.
> I hope that the stack t
(trimmed off the batman/bpf Ccs)
On 2020-05-18 14:28, syzbot wrote:
syzbot has bisected this bug to:
commit 0d8dd67be013727ae57645ecd3ea2c36365d7da8
Author: Song Liu
Date: Wed Dec 6 22:45:14 2017 +
perf/headers: Sync new perf_event.h with the tools/include/uapi version
bisection l
On 11/04/2021 09:58, Hao Sun wrote:
> Pavel Begunkov 于2021年4月11日周日 下午4:14写道：
>>
>> On 11/04/2021 04:08, Hao Sun wrote:
>>> Hi
>>>
>>> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
>>> the Linux kernel, I found a null-ptr-deref bug in
>>> io_uring_cancel_task_requests under
Pavel Begunkov 于2021年4月11日周日 下午4:14写道：
>
> On 11/04/2021 04:08, Hao Sun wrote:
> > Hi
> >
> > When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> > the Linux kernel, I found a null-ptr-deref bug in
> > io_uring_cancel_task_requests under fault injection condition, but I'm
> >
On 11/04/2021 04:08, Hao Sun wrote:
> Hi
>
> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> the Linux kernel, I found a null-ptr-deref bug in
> io_uring_cancel_task_requests under fault injection condition, but I'm
> not sure about this.
> Sorry, I do not have a reproduci
On 06/04/2021 17:40, Rafael J. Wysocki wrote:
On Tue, Apr 6, 2021 at 5:51 PM John Garry wrote:
Hi guys,
On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and
CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see this:
Hi Rafael,
Why exactly do you think that acpi_ev_install_space
On Tue, Apr 6, 2021 at 5:51 PM John Garry wrote:
>
> Hi guys,
>
> On next-20210406, I enabled CONFIG_DEBUG_KMEMLEAK and
> CONFIG_DEBUG_TEST_DRIVER_REMOVE for my arm64 system, and see this:
Why exactly do you think that acpi_ev_install_space_handler() leaks memory?
> root@debian:/home/john# more
On 4/3/2021 8:21 AM, Ondrej Mosnacek wrote:
On Sat, Apr 3, 2021 at 4:33 PM Paul Moore wrote:
On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
wrote:
Seeing oops in 5.4.83 sidtab_context_to_sid(). I checked with Tyler (copied),
he said it might be
https://lore.kernel.org/selinux/CAFqZX
> Am 04.04.2021 um 12:01 schrieb Greg KH :
>
> On Sun, Apr 04, 2021 at 11:29:00AM +0200, H. Nikolaus Schaller wrote:
>> it seems as if the patch
>>
>> 9de47c37 ("usb: dwc3: gadget: Prevent EP queuing while stopping
>> transfers") in v5.11.y
>> f09ddcfcb8c5 ("usb: dwc3: gadget: Pr
On Sun, Apr 04, 2021 at 11:29:00AM +0200, H. Nikolaus Schaller wrote:
> it seems as if the patch
>
> 9de47c37 ("usb: dwc3: gadget: Prevent EP queuing while stopping
> transfers") in v5.11.y
> f09ddcfcb8c5 ("usb: dwc3: gadget: Prevent EP queuing while stopping
> transfers") in v5.
On Sat, Apr 3, 2021 at 11:21 AM Ondrej Mosnacek wrote:
> On Sat, Apr 3, 2021 at 4:33 PM Paul Moore wrote:
> > On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
> > wrote:
> > >
> > > Seeing oops in 5.4.83 sidtab_context_to_sid(). I checked with Tyler
> > > (copied), he said it might be
> > >
>
On Sat, Apr 3, 2021 at 4:33 PM Paul Moore wrote:
> On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
> wrote:
> >
> > Seeing oops in 5.4.83 sidtab_context_to_sid(). I checked with Tyler
> > (copied), he said it might be
> >
> > https://lore.kernel.org/selinux/CAFqZXNu8s5edDbSZuSutetTsy58i08vPuP
On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
wrote:
>
> Seeing oops in 5.4.83 sidtab_context_to_sid(). I checked with Tyler
> (copied), he said it might be
>
> https://lore.kernel.org/selinux/CAFqZXNu8s5edDbSZuSutetTsy58i08vPuP2h-n9=kt34hcp...@mail.gmail.com/
>
> Ondrej, can you confirm? U
On Thu, Apr 01, 2021 at 12:00:39PM +0300, Dan Carpenter wrote:
> Hi Keith,
>
> I've been trying to figure out ways Smatch can check for device managed
> resources. Like adding rules that if we call dev_set_name(&foo->bar)
> then it's device managaged and if there is a kfree(foo) without calling
>
On Thu, Apr 01, 2021 at 08:25:11AM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 01, 2021 at 12:00:39PM +0300, Dan Carpenter wrote:
> > Hi Keith,
> >
> > I've been trying to figure out ways Smatch can check for device managed
> > resources. Like adding rules that if we call dev_set_name(&foo->bar)
On Thu, Apr 01, 2021 at 05:06:52PM +0300, Dan Carpenter wrote:
> > diff --git a/drivers/base/node.c b/drivers/base/node.c
> > index f449dbb2c74666..89c28952863977 100644
> > +++ b/drivers/base/node.c
> > @@ -319,25 +319,24 @@ void node_add_cache(unsigned int nid, struct
> > node_cache_attrs *cach
On Thu, Apr 01, 2021 at 12:00:39PM +0300, Dan Carpenter wrote:
> Hi Keith,
>
> I've been trying to figure out ways Smatch can check for device managed
> resources. Like adding rules that if we call dev_set_name(&foo->bar)
> then it's device managaged and if there is a kfree(foo) without calling
>
On 3/30/21 12:11 PM, Hao Sun wrote:
> Hi
>
> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> the Linux kernel, I found a use-after-free vulnerability in
> macvlan_broadcast.
> Hope the report can help you locate the problem.
>
> Details:
> commit: 5695e5161 Linux 5.1
On Mon, Mar 29 2021 at 08:36, Richard Cochran wrote:
> On Mon, Mar 29, 2021 at 04:57:55PM +0200, Thomas Gleixner wrote:
>> I think adjtimex is the right place and not yet another random file
>> somewhere. Something like the below.
>
> Perfect.
>
> Acked-by: Richard Cochran
But one problem is with
On Mon, Mar 29, 2021 at 04:57:55PM +0200, Thomas Gleixner wrote:
> I think adjtimex is the right place and not yet another random file
> somewhere. Something like the below.
Perfect.
Acked-by: Richard Cochran
> ---
> include/uapi/linux/timex.h |7 +--
> kernel/time/ntp.c |
On Mon, Mar 29 2021 at 07:26, Richard Cochran wrote:
> On Mon, Mar 29, 2021 at 11:16:48AM +0200, Miroslav Lichvar wrote:
>> There are at least two issues with handling a zero offset as a special
>> value. One is that zero could potentially be a valid value in distant
>> future.
>
> I not losing sle
On Mon, Mar 29, 2021 at 11:16:48AM +0200, Miroslav Lichvar wrote:
> There are at least two issues with handling a zero offset as a special
> value. One is that zero could potentially be a valid value in distant
> future.
I not losing sleep over that, but
> The other is that the kernel updates the
On Mon, Mar 29, 2021 at 11:16:48AM +0200, Miroslav Lichvar wrote:
> On Fri, Mar 26, 2021 at 08:28:59PM -0700, Richard Cochran wrote:
> > Using ntpd on Debian, the service will set the offset, but only after
> > synchronization with the upstream server has been established, and
> > this takes about
On Mon, Mar 29, 2021 at 11:56:31AM +0200, Daphne Preston-Kendal wrote:
> > The other is that the kernel updates the offset when a leap
> > second is inserted/deleted even if the original offset is zero, so
> > checking for zero (in the kernel or an application) works only until
> > the first leap s
> -原始邮件-
> 发件人: "Jan Kara"
> 发送时间: 2021-03-29 21:57:40 (星期一)
> 收件人: lyl2...@mail.ustc.edu.cn
> 抄送: j...@suse.cz, amir7...@gmail.com, linux-fsde...@vger.kernel.org,
> linux-kernel@vger.kernel.org
> 主题: Re: [BUG] fs/notify/mark: A potential use after fr
Hello!
On Sun 28-03-21 17:11:43, lyl2...@mail.ustc.edu.cn wrote:
> My static analyzer tool reported a use after free in
> fsnotify_put_mark_wake
> of the file: fs/notify/mark.c.
>
> In fsnotify_put_mark_wake, it calls fsnotify_put_mark(mark). Inside the
> function
> fsnotify_put_mark(), if
On 29 Mar 2021, at 11:16, Miroslav Lichvar wrote:
> On Fri, Mar 26, 2021 at 08:28:59PM -0700, Richard Cochran wrote:
>> Using ntpd on Debian, the service will set the offset, but only after
>> synchronization with the upstream server has been established, and
>> this takes about five minutes, II
On Fri, Mar 26, 2021 at 08:28:59PM -0700, Richard Cochran wrote:
> Using ntpd on Debian, the service will set the offset, but only after
> synchronization with the upstream server has been established, and
> this takes about five minutes, IIRC.
With the iburst option it shouldn't take more than 10
1 - 100 of 6819 matches
Mail list logo
