On 2021/04/19 11:22, 周传高 wrote:
> Some SOC vendors' drivers or user-mode processes may be in D state for a long
> time,
> and normally they do not configure HUNG TASK, so we need to ignore these
> tasks if
> we use HUNG TASK.
Isn't that a sign that the quality of the drivers and user-mode
On 2021/04/17 12:19, Tetsuo Handa wrote:
> On 2021/04/15 0:39, Andrey Konovalov wrote:
>> On Wed, Apr 14, 2021 at 7:45 AM Dmitry Vyukov wrote:
>>> The reproducer connects some USB HID device and communicates with the
>>> driver.
>>> Previously we observed reb
On 2021/04/17 23:13, zhouchuangao wrote:
> The main purpose of this patch is to add a whitelist and blacklist
> mechanism to the hung task thread.
We stopped using the term 'whitelist'/'blacklist' for new code in Linux kernel,
and what you are proposing is something like 'ignorelist'/'fatallist'.
On 2021/04/15 0:39, Andrey Konovalov wrote:
> On Wed, Apr 14, 2021 at 7:45 AM Dmitry Vyukov wrote:
>> The reproducer connects some USB HID device and communicates with the driver.
>> Previously we observed reboots because HID devices can trigger reboot
>> SYSRQ, but we disable it with
On 2021/04/15 19:04, Roberto Sassu wrote:
> This patch completes commit 9548906b2bb7 ('xattr: Constify ->name member of
> "struct xattr"'). It fixes the documentation of the inode_init_security
> hook, by removing the xattr name from the objects that are expected to be
> allocated by LSMs (only
7376dc7e90bc7d64a6a
Reported-by: syzbot
Reported-by: syzbot
Tested-by: syzbot
Signed-off-by: Tetsuo Handa
Fixes: 24b4b67d17c308aa ("add ttyprintk driver")
---
drivers/char/ttyprintk.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/char/ttyprintk.c b/drivers/char
On 2021/04/15 0:39, Andrey Konovalov wrote:
> On Wed, Apr 14, 2021 at 7:45 AM Dmitry Vyukov wrote:
>>
>> On Tue, Apr 13, 2021 at 11:27 PM syzbot
>> wrote:
>>>
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:89698bec Merge tag 'm68knommu-for-v5.12-rc7' of
On 2021/04/14 9:45, Tetsuo Handa wrote:
> On 2021/04/12 21:04, Greg Kroah-Hartman wrote:
>>> Since syzkaller is a fuzzer, syzkaller happily opens /dev/ttyprintk from
>>> multiple threads. Should we update syzkaller to use CONFIG_TTY_PRINTK=n ?
>>
>> Why? Can yo
On 2021/04/12 21:04, Greg Kroah-Hartman wrote:
>> Since syzkaller is a fuzzer, syzkaller happily opens /dev/ttyprintk from
>> multiple threads. Should we update syzkaller to use CONFIG_TTY_PRINTK=n ?
>
> Why? Can you not hit the same tty code paths from any other tty driver
> being open multiple
Commit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write
functions") missed that count > SMK_CIPSOMAX check applies to only
format == SMK_FIXED24_FMT case.
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
---
security/smack/smackfs.c | 2 ++
1 file changed, 2 insert
On 2021/04/12 19:44, Greg Kroah-Hartman wrote:
> And trying to "open exclusive only" just does not work, the kernel can
> not enforce that at all, sorry. Any driver that you see trying to do
> that is trivial to work around in userspace, making the kernel code
> pointless.
You mean something
/ttyprintk ?
If we can't change /dev/ttyprintk exclusively open()able by only
one thread, how to handle concurrent access to /dev/ttyprintk ?
On 2021/04/07 23:24, Tetsuo Handa wrote:
> On 2021/04/07 22:48, Greg Kroah-Hartman wrote:
>>> By the way, as soon as applying this pa
The following commit has been merged into the irq/core branch of tip:
Commit-ID: c5e3a41187ac01425f5ad1abce927905e4ac44e4
Gitweb:
https://git.kernel.org/tip/c5e3a41187ac01425f5ad1abce927905e4ac44e4
Author:Tetsuo Handa
AuthorDate:Thu, 01 Apr 2021 14:58:23 +09:00
Committer
On 2021/04/08 21:51, Greg Kroah-Hartman wrote:
> Remove users of tty_warn() and replace them with calls to dev_warn()
> which provides more information about the tty that has the error and
> uses the standard formatting logic.
Ouch. This series would be good for clean up, but this series might be
On 2021/04/07 22:48, Greg Kroah-Hartman wrote:
>> By the way, as soon as applying this patch, I guess that syzkaller starts
>> generating hung task reports because /dev/ttyprintk can trivially trigger
>> flood of
>>
>> tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__,
>>
dding
if (strcmp(tty_driver_name(tty), "ttyprintk"))
immediately before this tty_warn() gave me Tested-by: response.
[1]
https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a
Reported-by: syzbot
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Fixes: b6da31b2c07c46f2 (
On 2021/04/07 0:10, Petr Mladek wrote:
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index 6d4995a5f318..d59f7873bc49 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++ b/drivers/tty/tty_buffer.c
>> @@ -156,6 +156,7 @@ static struct tty_buffer *tty_buffer_alloc(struct
>>
On 2021/04/06 16:10, Greg Kroah-Hartman wrote:
> On Tue, Apr 06, 2021 at 02:31:43PM +0900, Tetsuo Handa wrote:
>> On 2021/04/06 13:51, Jiri Slaby wrote:
>>> On 03. 04. 21, 6:14, Tetsuo Handa wrote:
>>>> --- a/include/linux/tty.h
>>>> +++ b/include/linux/tt
On 2021/04/06 13:51, Jiri Slaby wrote:
> On 03. 04. 21, 6:14, Tetsuo Handa wrote:
>> --- a/include/linux/tty.h
>> +++ b/include/linux/tty.h
>> @@ -14,6 +14,7 @@
>> #include
>> #include
>> #include
>> +#include <../../kernel/printk/int
values (default value + 1 should be OK).
On 2021/03/31 19:58, Tetsuo Handa wrote:
> Peter, are you there?
>
> If you keep silence, we will assume that applying this patch is the way to go.
>
> On 2021/03/20 16:34, Dmitry Vyukov wrote:
>> On Mon, Feb 8, 2021 at 11:29 AM T
rnal.h be #include'd for multiple times, let's fix
this problem first.
Reported-by: kernel test robot
Signed-off-by: Tetsuo Handa
Fixes: 099f1c84c0052ec1 ("printk: introduce per-cpu safe_print seq buffer")
Cc: # 4.11+
---
kernel/printk/internal.h | 8 +++-
1 file changed, 7 insertions
=39ea6caa479af471183997376dc7e90bc7d64a6a
[2] https://lkml.kernel.org/r/20190218054649.GA26686@jagdpanzerIV
Reported-by: syzbot
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Fixes: b6da31b2c07c46f2 ("tty: Fix data race in
tty_insert_flip_string_fixed_flag")
Cc: # 4.18+
---
d
=
Signed-off-by: Tetsuo Handa
Fixes: 1f166439917b69d3 ("VMCI: guest side driver implementation.")
Cc:
---
drivers/misc/vmw_vmci/vmci_guest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index cc
vmci_dbell_register_notification_bitmap+0x50/0x1e0
Bytes 28-31 of 32 are uninitialized
Memory access of size 32 starts at 88810098f570
=
Signed-off-by: Tetsuo Handa
Fixes: 83e2ec765be03e8a ("VMCI: doorbell implementation.")
Cc:
---
dr
On 2021/04/01 15:18, Greg Kroah-Hartman wrote:
> On Thu, Apr 01, 2021 at 02:57:47PM +0900, Tetsuo Handa wrote:
>> KMSAN complains that the vmci_use_ppn64() == false path in
>> vmci_dbell_register_notification_bitmap() left upper 32bits of
>> bitmap_set_msg.bitmap_ppn64
-off-by: Tetsuo Handa
---
kernel/irq/proc.c| 4 ++--
kernel/profile.c | 2 +-
kernel/trace/trace.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index 98138788cb04..7c5cd42df3b9 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq
personality initialized and is active
[ 21.642165][T1] VMCI host device registered (name=vmci, major=10,
minor=121)
Signed-off-by: Tetsuo Handa
---
drivers/misc/vmw_vmci/vmci_doorbell.c | 2 +-
drivers/misc/vmw_vmci/vmci_guest.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
Peter, are you there?
If you keep silence, we will assume that applying this patch is the way to go.
On 2021/03/20 16:34, Dmitry Vyukov wrote:
> On Mon, Feb 8, 2021 at 11:29 AM Tetsuo Handa
> wrote:
>>
>> Since syzkaller continues various test cases until the kernel crashes,
On 2021/03/24 20:10, Mimi Zohar wrote:
> On Wed, 2021-03-24 at 19:10 +0900, Tetsuo Handa wrote:
>> On 2021/03/24 1:13, Mimi Zohar wrote:
>>> On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote:
>>>> On 2021/03/23 23:47, Mimi Zohar wrote:
>>>>>
On 2021/03/24 1:13, Mimi Zohar wrote:
> On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote:
>> On 2021/03/23 23:47, Mimi Zohar wrote:
>>> Initially I also questioned making "integrity" an LSM. Perhaps it's
>>> time to reconsider. For now, it makes s
On 2021/03/23 23:47, Mimi Zohar wrote:
> Initially I also questioned making "integrity" an LSM. Perhaps it's
> time to reconsider. For now, it makes sense to just fix the NULL
> pointer dereferencing.
Do we think calling panic() as "fix the NULL pointer dereferencing" ?
On 2021/03/23 22:37, Tetsuo Handa wrote:
> On 2021/03/23 21:09, Mimi Zohar wrote:
>> Please take a look at the newer version of this patch. Do you want to
>> add any tags?
>
> Oh, I didn't know that you already posted the newer version.
>
>> diff --git a/securi
On 2021/03/23 21:09, Mimi Zohar wrote:
> Please take a look at the newer version of this patch. Do you want to
> add any tags?
Oh, I didn't know that you already posted the newer version.
> diff --git a/security/integrity/iint.c b/security/integrity/iint.c
> index 1d20003243c3..0ba01847e836
On 2021/03/20 5:03, Mimi Zohar wrote:
> The integrity's "iint_cache" is initialized at security_init(). Only
> after an IMA policy is loaded, which is initialized at late_initcall,
> is a file's integrity status stored in the "iint_cache".
>
> All integrity_inode_get() callers first verify that
On 2021/03/20 5:03, Mimi Zohar wrote:
> The integrity's "iint_cache" is initialized at security_init(). Only
> after an IMA policy is loaded, which is initialized at late_initcall,
> is a file's integrity status stored in the "iint_cache".
>
> All integrity_inode_get() callers first verify that
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 3a85969e9d912d5dd85362ee37b5f81266e00e77
Gitweb:
https://git.kernel.org/tip/3a85969e9d912d5dd85362ee37b5f81266e00e77
Author:Tetsuo Handa
AuthorDate:Sun, 21 Mar 2021 15:49:13 +09:00
-by: Tetsuo Handa
---
kernel/locking/lockdep.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index c6d0c1dc6253..44c549f5c061 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -931,6 +931,7 @@ static bool
Peter, would you answer to 6 questions listed below?
Below is a reproducer kernel module (prefixed with "my_" for distinction) for
https://syzkaller.appspot.com/bug?id=38c060d5757cbc13fdffd46e80557c645fbe79ba .
-- test.c --
#include
#include
#include <../fs/ext4/ext4.h>
static
On 2021/03/12 0:54, Marco Elver wrote:
>> But the more we could have the compiler automatically figure out
>> things without needing an explicit tag, it would seem to me that this
>> would be better, since manual tagging is going to be more error-prone.
>
> What you're alluding to here would go
On 2021/03/18 22:13, Shuah Khan wrote:
> Please don't review code that isn't sent upstream. This repo you are
> looking at is a private branch created just to verify fixes on syzbot.
But nobody was able to review this series when sent to ML (except you simply
ignored my questions), and this
On 2021/03/18 0:06, Shuah Khan wrote:
> Yes. I haven't sent the patch for that reason. I am trying to test a
> solution. I haven't come up with a solution yet.
>
> Holding event_lock isn't the right solution. I am not going to accept
> that. This is a window that gets triggered by syzbot
Shuah, this driver is getting more and more cryptic and buggy.
Please explain the strategy for serialization before you write patches.
> - Fix attach_store() to check usbip_event_happened() before
> waking up threads.
No, this helps nothing.
> diff --git a/drivers/usb/usbip/vhci_sysfs.c
On 2021/03/13 9:48, Tetsuo Handa wrote:
> On 2021/03/12 14:44, Tetsuo Handa wrote:
>> And what you are missing in your [PATCH 4,5,6/6] is
>>
>> diff --git a/drivers/usb/usbip/vhci_sysfs.c
>> b/drivers/usb/usbip/vhci_sysfs.c
>> index c4457026d5ad..3c64bd06a
On 2021/03/12 14:44, Tetsuo Handa wrote:
> And what you are missing in your [PATCH 4,5,6/6] is
>
> diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
> index c4457026d5ad..3c64bd06ab53 100644
> --- a/drivers/usb/usbip/vhci_sysfs.c
> +++ b
I cloned git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux.git as you
are testing changes there.
> commit 09e4522c87ff54c655c09f318a68b012eda8eb01 (HEAD -> usbip_test,
> origin/usbip_test)
> Author: Shuah Khan
> Date: Thu Mar 11 11:18:25 2021 -0700
>
>usbip: fix vhci races in
On 2021/03/11 21:57, Greg KH wrote:
> On Thu, Mar 11, 2021 at 09:34:38PM +0900, Tetsuo Handa wrote:
>> On 2021/03/11 3:33, Greg KH wrote:
>>> On Sun, Mar 07, 2021 at 08:53:25PM -0700, Shuah Khan wrote:
>>>> This patch series fixes the following problems
On 2021/03/11 3:33, Greg KH wrote:
> On Sun, Mar 07, 2021 at 08:53:25PM -0700, Shuah Khan wrote:
>> This patch series fixes the following problems founds in syzbot
>> fuzzing.
>
> Thanks for these, all now queued up.
I send SIGSTOP to
[PATCH 4/6] usbip: fix stub_dev usbip_sockfd_store() races
On 2021/03/10 11:07, Shuah Khan wrote:
> On 3/9/21 6:02 PM, Tetsuo Handa wrote:
>> On 2021/03/10 9:29, Shuah Khan wrote:
>>>> It is not a large grain lock. Since event_handler() is exclusively
>>>> executed, this lock
>>>> does _NOT_ block event_
On 2021/03/10 9:29, Shuah Khan wrote:
>> It is not a large grain lock. Since event_handler() is exclusively executed,
>> this lock
>> does _NOT_ block event_handler() unless attach/detach operations run
>> concurrently.
>>
>>>
>
> event handler queues the events. It shouldn't be blocked by
On 2021/03/10 8:52, Shuah Khan wrote:
> On 3/9/21 4:40 PM, Tetsuo Handa wrote:
>> On 2021/03/10 4:50, Shuah Khan wrote:
>>> On 3/9/21 4:04 AM, Tetsuo Handa wrote:
>>>> On 2021/03/09 1:27, Shuah Khan wrote:
>>>>> Yes. We might need synchron
On 2021/03/10 4:50, Shuah Khan wrote:
> On 3/9/21 4:04 AM, Tetsuo Handa wrote:
>> On 2021/03/09 1:27, Shuah Khan wrote:
>>> Yes. We might need synchronization between events, threads, and shutdown
>>> in usbip_host side and in connection polling and threads in vhci
On 2021/03/09 20:04, Tetsuo Handa wrote:
> On 2021/03/09 1:27, Shuah Khan wrote:
>> Yes. We might need synchronization between events, threads, and shutdown
>> in usbip_host side and in connection polling and threads in vhci.
>>
>> I am also looking at the shutdown sequ
On 2021/03/09 1:27, Shuah Khan wrote:
> Yes. We might need synchronization between events, threads, and shutdown
> in usbip_host side and in connection polling and threads in vhci.
>
> I am also looking at the shutdown sequences closely as well since the
> local state is referenced without
On 2021/03/08 16:35, Tetsuo Handa wrote:
> On 2021/03/08 12:53, Shuah Khan wrote:
>> Fix the above problems:
>> - Stop using kthread_get_run() macro to create/start threads.
>> - Create threads and get task struct reference.
>> - Add kthread_create() failure handl
On 2021/03/08 12:53, Shuah Khan wrote:
> Fix the above problems:
> - Stop using kthread_get_run() macro to create/start threads.
> - Create threads and get task struct reference.
> - Add kthread_create() failure handling and bail out.
> - Hold usbip_device lock to update local and shared states
On 2021/03/06 22:03, Jia-Ju Bai wrote:
> When mutex_lock_interruptible() fails, the error return code of
> tomoyo_update_domain() is not properly assigned.
> To fix this bug, error is assigned with the return value of
> mutex_lock_interruptible(), and then error is checked.
Thanks for a patch,
On 2021/02/15 23:29, Jan Kara wrote:
> On Mon 15-02-21 23:06:15, Tetsuo Handa wrote:
>> On 2021/02/15 21:45, Jan Kara wrote:
>>> On Sat 13-02-21 23:26:37, Tetsuo Handa wrote:
>>>> Excuse me, but it seems to me that nothing prevents
>>>
On 2021/02/15 21:45, Jan Kara wrote:
> On Sat 13-02-21 23:26:37, Tetsuo Handa wrote:
>> Excuse me, but it seems to me that nothing prevents
>> ext4_xattr_set_handle() from reaching ext4_xattr_inode_lookup_create()
>> without memalloc_nofs_save() when hitting ext4_get_nojourna
pstore_kill_sb() when pstore_fill_super()
failed, pstore_kill_sb() needs to be aware of such failure path.
[1]
https://syzkaller.appspot.com/bug?id=6abacb8da5137cb47a416f2bef95719ed60508a0
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
---
fs/pstore/inode.c | 2 +-
1 file changed, 1
On 2021/02/11 19:49, Jan Kara wrote:
> This stacktrace should never happen. ext4_xattr_set() starts a transaction.
> That internally goes through start_this_handle() which calls:
>
> handle->saved_alloc_context = memalloc_nofs_save();
>
> and we restore the allocation context only in
for fixing "general protection fault in
tomoyo_socket_sendmsg_permission" will kill kthread_get_run().
Closing frequently crashing bug now is the better.
On 2021/02/11 22:40, Tetsuo Handa wrote:
> I guess that we need to serialize attach operation and reset/detach
> operations
On 2021/02/12 22:12, Michal Hocko wrote:
> On Fri 12-02-21 21:58:15, Tetsuo Handa wrote:
>> On 2021/02/12 21:30, Michal Hocko wrote:
>>> On Fri 12-02-21 12:22:07, Matthew Wilcox wrote:
>>>> On Fri, Feb 12, 2021 at 08:18:11PM +0900, Tetsuo Handa wrote:
>>>&g
On 2021/02/12 21:30, Michal Hocko wrote:
> On Fri 12-02-21 12:22:07, Matthew Wilcox wrote:
>> On Fri, Feb 12, 2021 at 08:18:11PM +0900, Tetsuo Handa wrote:
>>> On 2021/02/12 1:41, Michal Hocko wrote:
>>>> But I suspect we have drifted away from the original issue
On 2021/02/12 1:41, Michal Hocko wrote:
> But I suspect we have drifted away from the original issue. I thought
> that a simple check would help us narrow down this particular case and
> somebody messing up from the IRQ context didn't sound like a completely
> off.
>
From my experience at
On 2021/02/12 11:22, Tetsuo Handa wrote:
> On 2021/02/12 10:34, Shuah Khan wrote:
>> On 2/10/21 6:14 PM, Tetsuo Handa wrote:
>>> (Dropping LSM ML because this is not a TOMOYO's bug.)
>>>
>>> On 2021/02/11 4:29, Shuah Khan wrote:
>>>> This is a go
On 2021/02/12 10:34, Shuah Khan wrote:
> On 2/10/21 6:14 PM, Tetsuo Handa wrote:
>> (Dropping LSM ML because this is not a TOMOYO's bug.)
>>
>> On 2021/02/11 4:29, Shuah Khan wrote:
>>> This is a good find. I already replied to the thread to send a complete
>>
(Dropping LSM ML because this is not a TOMOYO's bug.)
On 2021/02/11 4:29, Shuah Khan wrote:
> This is a good find. I already replied to the thread to send a complete
> fix.
As I said at
https://lkml.kernel.org/r/f8cae6b1-8f84-0e6a-7d9c-fc4aec68f...@i-love.sakura.ne.jp
,
the as-is patch is
On 2021/02/11 3:17, Shuah Khan wrote:
> I am looking to understand the syzbot configuration and a reproducer
> to be able to debug and fix the problem. How is syzbot triggering the
> vhci_hcd attach and detach sequence?
I don't know. I'm waiting for syzbot to reproduce the problem on linux-next
On 2021/02/11 1:54, Andy Shevchenko wrote:
> On Thu, Feb 11, 2021 at 01:39:41AM +0900, Tetsuo Handa wrote:
>> On 2021/02/11 1:18, Steven Rostedt wrote:
>>> The point of this exercise is to be able to debug the *same* kernel that
>>> someone is having issues with
On 2021/02/11 1:46, Steven Rostedt wrote:
> On Thu, 11 Feb 2021 01:39:41 +0900
> Tetsuo Handa wrote:
>
>> On 2021/02/11 1:18, Steven Rostedt wrote:
>>> The point of this exercise is to be able to debug the *same* kernel that
>>> someone is having issue
On 2021/02/11 1:18, Steven Rostedt wrote:
> The point of this exercise is to be able to debug the *same* kernel that
> someone is having issues with. And this is to facilitate that debugging.
That's too difficult to use. If a problem is not reproducible, we will have
no choice but always specify
On 2021/02/10 14:18, Timur Tabi wrote:
> [accidentally sent from the wrong email address, so resending]
>
> [The list of email addresses on CC: is getting quite lengthy,
> so I hope I've included everyone.]
>
> Although hashing addresses printed via printk does make the
> kernel more secure, it
-by: syzbot
References:
https://lkml.kernel.org/r/1595640639-9310-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
Signed-off-by: Tetsuo Handa
Acked-by: Dmitry Vyukov
---
kernel/locking/lockdep.c | 2 +-
kernel/locking/lockdep_internals.h | 8 +++---
lib/Kconfig.debug
Hello, Andrew and Linus.
We are stuck because Peter cannot respond.
I think it is time to send this patch to linux-next. What do you think?
On 2021/01/20 19:18, Dmitry Vyukov wrote:
> On Wed, Jan 20, 2021 at 11:12 AM Tetsuo Handa
> wrote:
>>
>> Since syzkaller continues variou
On 2021/01/30 6:18, Shuah Khan wrote:
> In this console log:
It seems "this console log" refers to
https://syzkaller.appspot.com/x/log.txt?x=1045303450 .
>
> 06:57:50 executing program 1:
> socketpair$tipc(0x1e, 0x2, 0x0, &(0x7fc0)={0x})
>
On 2021/01/30 1:05, Shuah Khan wrote:
>> Since "general protection fault in tomoyo_socket_sendmsg_permission" is
>> caused by
>> unexpectedly resetting ud->tcp_socket to NULL without waiting for tx thread
>> to
>> terminate, tracing the ordering of events is worth knowing. Even adding
>>
On 2021/01/29 4:05, Shuah Khan wrote:
> The reason I don't like adding printk's is this is a race condition
> and as a result time sensitive. Adding printks in the path will not
> help debug this issue. It will make it harder to reproduce the problem.
Not always. Adding printk() might make it
On 2021/01/28 22:27, Sabyrzhan Tasbolatov wrote:
>> Doesn't this change break legitimate requests like
>>
>> char buffer[2];
>>
>> memset(buffer, ' ', sizeof(buffer));
>> memcpy(buffer + sizeof(buffer) - 10, "foo", 3);
>> write(fd, buffer, sizeof(buffer));
>>
>> ?
>
> It does, in this
On 2021/01/28 20:58, Sabyrzhan Tasbolatov wrote:
> @@ -2005,6 +2009,9 @@ static ssize_t smk_write_onlycap(struct file *file,
> const char __user *buf,
> if (!smack_privileged(CAP_MAC_ADMIN))
> return -EPERM;
>
> + if (count > PAGE_SIZE)
> + return -EINVAL;
>
: vhci_hcd: add printk() for debug
This is linux-next only patch for examining a bug reported at
https://syzkaller.appspot.com/bug?id=3e1d941a31361efc4ced2ba8b4af2044d4e43c59 .
Signed-off-by: Tetsuo Handa
---
drivers/usb/usbip/stub_dev.c | 6 ++
drivers/usb/usbip/vhci_hcd.c | 11
On 2021/01/26 3:08, Casey Schaufler wrote:
> On 1/24/2021 6:36 AM, Sabyrzhan Tasbolatov wrote:
>> syzbot found WARNINGs in several smackfs write operations where
>> bytes count is passed to memdup_user_nul which exceeds
>> GFP MAX_ORDER. Check count size if bigger SMK_LONGLABEL,
>> for
On 2021/01/23 20:26, Alexey Kardashevskiy wrote:
> Should not the first 8192 from "grep lock-classes /proc/lockdep_stats"
> decrease
> after time (it does not), or once it has failed, it is permanent?
Since lockdep_unregister_key() becomes a no-op because graph_lock() returns 0
due to
On 2021/01/23 15:35, Alexey Kardashevskiy wrote:
> this behaves quite different but still produces the message (i have
> show_workqueue_state() right after the bug message):
>
>
> [ 85.803991] BUG: MAX_LOCKDEP_KEYS too low!
> [ 85.804338] turning off the locking correctness validator.
> [
bpf_map_free_deferred from completing? Please see
https://lkml.kernel.org/r/CACT4Y+Z+kwPM=WUzJ-e359PWeLLqmF0w4Yxp1spzZ=+j0ek...@mail.gmail.com
.
On 2021/01/23 7:53, Alexey Kardashevskiy wrote:
>
>
> On 23/01/2021 02:30, Tetsuo Handa wrote:
>> On 2021/01/22 22:28, Tetsuo Handa wrote:
>>
rted-by: syzbot
Signed-off-by: Tetsuo Handa
Acked-by: Dmitry Vyukov
---
kernel/locking/lockdep.c | 2 +-
kernel/locking/lockdep_internals.h | 8 +++---
lib/Kconfig.debug | 40 ++
3 files changed, 45 insertions(+), 5 deletions(-)
diff
On 2021/01/08 0:48, xuhuijie wrote:
> This commit 50145474f6ef(fbcon: remove soft scrollback code) remove soft
> scrollback in
> fbcon. So the shift+PageDown and shift+PageUp is missing. But PageUp is a
> vary important
> feature when system panic or reset. I can get log by PageUp before, but
On 2021/01/05 16:59, Christoph Hellwig wrote:
> On Wed, Dec 23, 2020 at 07:11:38PM +0900, Tetsuo Handa wrote:
>> due to commit 5e6e9852d6f76e01 ("uaccess: add infrastructure for kernel
>> builds with set_fs()") and follow up changes. Don't we need to chang
l.kernel.org/r/1c351187-253b-2d49-acaf-4563c63ae...@i-love.sakura.ne.jp
Reported-by: syzbot
Reported-by: syzbot
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Acked-by: Dmitry Vyukov
---
kernel/locking/lockdep.c | 2 +-
kernel/locking/lockdep_internals.h | 8 ++
On 2020/12/23 16:53, Christoph Hellwig wrote:
> On Tue, Dec 22, 2020 at 11:39:08PM +0900, Tetsuo Handa wrote:
>> For example, if uaccess_kernel() is "false" due to CONFIG_SET_FS=n,
>> isn't sg_check_file_access() failing to detect kernel context?
>
> sg_check_fil
Commit db68ce10c4f0a27c ("new helper: uaccess_kernel()") replaced
segment_eq(get_fs(), KERNEL_DS)
with uaccess_kernel(). But uaccess_kernel() became an unconditional "false" for
some architectures
due to commit 5e6e9852d6f76e01 ("uaccess: add infrastructure for kernel builds
with set_fs()") and
On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney wrote:
> In my experience, lockdep will indeed complain if an interrupt handler
> returns while in an RCU read-side critical section.
Can't we add lock status checks into the beginning and the end of interrupt
handler functions
(e.g. whether
On 2020/12/18 21:59, Pavel Machek wrote:
> On Fri 2020-12-18 19:44:04, Xiaoming Ni wrote:
> Plus.. is_being_panic is not really english. "is_paniccing" would be
> closer...?
Or in_panic() ?
On 2020/12/08 1:32, Miklos Szeredi wrote:
> A general observation is that overlayfs does not call security_path_*()
> hooks on the underlying fs. I don't see this as a problem, because a
> simple bind mount done inside a private mount namespace also defeats the
> path based security checks.
I attempted some analysis, but I couldn't find which lock is causing
nr_list_entries == 32768.
Since "struct lock_list list_entries[MAX_LOCKDEP_ENTRIES]" is marked as
"static" variable in lockdep.c ,
none of /proc/lockdep_stats /proc/lockdep /proc/lockdep_chains can report which
lock is
On Sun, Nov 22, 2020 at 2:56 AM Tetsuo Handa
wrote:
> Peter, you guessed that the culprit is sysfs at
> https://lkml.kernel.org/r/20200916115057.go2...@hirez.programming.kicks-ass.net
> , but
> syzbot reported at
> https://syzkaller.appspot.com/text?tag=MachineInfo=99b8f2b092d97
On 2020/11/27 16:17, Zheng Zengkai wrote:
> Hello Tetsuo,
>> On 2020/11/26 15:33, Zheng Zengkai wrote:
>>> As your say, I found the function tomoyo_assign_namespace( )
>>>
>>> in security/tomoyo/domain.c has the similar situation,
>>>
>>> Can I add __GFP_NOWARN for both and remove the null check
On 2020/11/26 15:33, Zheng Zengkai wrote:
> As your say, I found the function tomoyo_assign_namespace( )
>
> in security/tomoyo/domain.c has the similar situation,
>
> Can I add __GFP_NOWARN for both and remove the null check for _entry_ in
> tomoyo_assign_namespace( )?
>
Good catch. Yes,
obot
> Signed-off-by: Zheng Zengkai
Nacked-by: Tetsuo Handa
> ---
> security/tomoyo/common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c
> index 4bee32bfe16d..99b4fafcb100 100644
> --- a/security/tomoyo/c
On 2020/11/20 18:27, Dmitry Vyukov wrote:
> Peter, so far it looks like just a very large, but normal graph to me.
> The cheapest from an engineering point of view solution would be just
> to increase the constants. I assume a 2x increase should buy us lots
> of time to overflow.
> I can think of
On 2020/11/19 23:30, Dmitry Vyukov wrote:
> p.s. it's indeed huge, full log was 11MB, this probably won't be
> chewed by syzbot.
Is "cat /proc/lockdep*" output written from userspace?
Then, we could try "xz -9" + "base64" for recording.
> Peter, are these [hex numbers] needed? Could we strip
1 - 100 of 3816 matches
Mail list logo
