Re: Duplicate crash reports related with smsc75xx/smsc95xx and root cause analysis

On Sat, Jan 23, 2021 at 1:40 PM 慕冬亮 wrote: > > Dear kernel developers, > > I found that on the syzbot dashboard, “KMSAN: uninit-value in > smsc75xx_read_eeprom (2)” [1], > "KMSAN: uninit-value in smsc95xx_read_eeprom (2)" [2], "KMSAN: > uninit-value in smsc75

Duplicate crash reports related with smsc75xx/smsc95xx and root cause analysis

Dear kernel developers, I found that on the syzbot dashboard, “KMSAN: uninit-value in smsc75xx_read_eeprom (2)” [1], "KMSAN: uninit-value in smsc95xx_read_eeprom (2)" [2], "KMSAN: uninit-value in smsc75xx_bind" [3], "KMSAN: uninit-value in smsc95xx_reset" [4], "KMSAN: uninit-value in

Re: "possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors

On Thu, Jan 21, 2021 at 8:49 PM Lukas Bulwahn wrote: > > On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮 wrote: > > > > Dear kernel developers, > > > > I found that on the syzbot dashboard, “possible deadlock in > > console_lock_spinning_enable”[1] and "possible

"KMSAN: uninit-value in rt2500usb_bbp_read" and "KMSAN: uninit-value in rt2500usb_probe_hw" should be duplicate crash reports

Dear kernel developers, I found that on the syzbot dashboard, “KMSAN: uninit-value in rt2500usb_bbp_read” [1] and "KMSAN: uninit-value in rt2500usb_probe_hw" [2] should share the same root cause. ## Duplication The reasons for the above statement: 1) The PoCs are exactly the same with each

"WARNING in cgroup_finalize_control" and "WARNING in cgroup_apply_control_disable" should be duplicate crash reports

Dear kernel developers, I found that on the syzbot dashboard, “WARNING in cgroup_finalize_control” [1] and "WARNING in cgroup_apply_control_disable" [2] should share the same root cause. The reasons for the above statement: 1) the stack trace is the same, and this title difference is due to the

Re: [PATCH] rt2x00: reset reg earlier in rt2500usb_register_read

On Thu, Jan 21, 2021 at 7:21 PM Greg KH wrote: > > On Thu, Jan 21, 2021 at 06:59:08PM +0800, 慕冬亮 wrote: > > > > rt2x00usb_vendor_request_buff(rt2x00dev, USB_MULTI_READ, > > > >

Re: [PATCH] rt2x00: reset reg earlier in rt2500usb_register_read

On Thu, Jan 21, 2021 at 5:49 PM Greg KH wrote: > > On Thu, Jan 21, 2021 at 05:20:26PM +0800, Dongliang Mu wrote: > > In the function rt2500usb_register_read(_lock), reg is uninitialized > > in some situation. Then KMSAN reports uninit-value at its first memory > > access. To fix this issue, add

Re: "KMSAN: uninit-value in rt2500usb_bbp_read" and "KMSAN: uninit-value in rt2500usb_probe_hw" should be duplicate crash reports

On Thu, Jan 21, 2021 at 4:52 PM Greg KH wrote: > > On Thu, Jan 21, 2021 at 04:47:37PM +0800, 慕冬亮 wrote: > > Dear kernel developers, > > > > I found that on the syzbot dashboard, “KMSAN: uninit-value in > > rt2500usb_bbp_read” [1] and "KMSAN: uninit-value in

"INFO: task hung in exit_mm" and "INFO: task hung in do_exit" should be duplicate crash reports

Dear kernel developers, I found that on the syzbot dashboard, “INFO: task hung in exit_mm”[1] and "INFO: task hung in do_exit"[2] should share the same root cause. The reasons for the above statement: 1) the stack trace is the same, and this title difference is due to the inline property of

"possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors

Dear kernel developers, I found that on the syzbot dashboard, “possible deadlock in console_lock_spinning_enable”[1] and "possible deadlock in console_unlock"[2] should share the same root cause. The reasons for the above statement: 1) the stack trace is the same, and this title difference is

"WARNING: refcount bug in qrtr_node_lookup" and "WARNING: refcount bug in qrtr_recvmsg" should share the same root cause

Dear kernel developers, I found that on the syzbot dashboard, “WARNING: refcount bug in qrtr_node_lookup”[1] and "WARNING: refcount bug in qrtr_recvmsg"[2] should share the same root cause. The reasons for the above statement: 1) the stack trace is the same, and this title difference is due to

"possible deadlock in static_key_slow_dec" and "possible deadlock in __static_key_slow_dec" should share the same root cause

Dear kernel developers, I found that on the syzbot dashboard, “possible deadlock in static_key_slow_dec” [1] and "possible deadlock in __static_key_slow_dec" [2] should share the same root cause. The reasons for the above statement: 1) the stack trace is the same, and this title difference is

"WARNING: locking bug in finish_task_switch" and "WARNING: locking bug in finish_lock_switch" should share the same root cause

Dear kernel developers, I found that on the syzbot dashboard, “WARNING: locking bug in finish_task_switch”[1] and "WARNING: locking bug in finish_lock_switch"[2] should share the same root cause. The reasons for the above statement: 1) the stack trace is the same, and this title difference is

“KASAN: null-ptr-deref Write in event_handler” and "KASAN: null-ptr-deref Write in vhci_shutdown_connection" should share the same root cause.

Dear kernel developers, I found that on the syzbot dashboard, “KASAN: null-ptr-deref Write in event_handler”[1] and "KASAN: null-ptr-deref Write in vhci_shutdown_connection" () should share the same root cause. The reasons for the above statement: 1) the stack trace is the same, and this title

Re: [PATCH] Fix shift-out-of-bound in mceusb_process_ir_data

On Wed, Jan 13, 2021 at 10:27 PM Sean Young wrote: > > On Wed, Jan 13, 2021 at 07:11:22PM +0800, Dongliang Mu wrote: > > The missing check of ir->buf_in[i+1] can lead to an shift-out-of-bound > > in mceusb_handle_command or mceusb_dev_printdata. This patch adds a > > check to limit its value

“KASAN: slab-out-of-bounds Read in squashfs_get_id” should have the same root cause with "KASAN: use-after-free Read in squashfs_get_id"

Dear kernel developers, I found that on the syzbot dashboard, “KASAN: slab-out-of-bounds Read in squashfs_get_id” (https://syzkaller.appspot.com/bug?id=16a7f16e9182bbfdbd2142306a82a41d4debb670) and "KASAN: use-after-free Read in squashfs_get_id"

"WARNING: locking bug in do_ipv6_setsockopt" should share the same root cause with "WARNING: locking bug in do_ipv6_getsockopt"

I found that on the syzbot dashboard, “WARNING: locking bug in do_ipv6_setsockopt”(https://syzkaller.appspot.com/bug?id=6a970baf20aa5a64455be86fb920f468def703c6) and "WARNING: locking bug in do_ipv6_getsockopt" (https://syzkaller.appspot.com/bug?id=e97be0bf4d30813e951bcc6249e72c592a790164) should

KASAN: use-after-free Read in ath9k_hif_usb_rx_cb (2) should share the same root cause with "KASAN: slab-out-of-bounds Read in ath9k_hif_usb_rx_cb (2)"

Dear kernel developers, I found that KASAN: use-after-free Read in ath9k_hif_usb_rx_cb (2) and "KASAN: slab-out-of-bounds Read in ath9k_hif_usb_rx_cb (2)" should share the same root cause. The reasons for my above statement, 1) the stack trace is the same; 2) we observed two crash behaviors

Re: "UBSAN: shift-out-of-bounds in mceusb_dev_recv" should share the same root cause with "UBSAN: shift-out-of-bounds in mceusb_dev_printdata"

On Wed, Jan 13, 2021 at 3:51 PM Greg KH wrote: > > On Wed, Jan 13, 2021 at 01:04:44PM +0800, 慕冬亮 wrote: > > Hi developers, > > > > I found that "UBSAN: shift-out-of-bounds in mceusb_dev_recv" and > > "UBSAN: shift-out-of-bounds in mceusb_dev_pr

"KASAN: vmalloc-out-of-bounds Read in bpf_trace_run1/2/3/5" and "BUG: unable to handle kernel paging request in bpf_trace_run1/2/3/4" should share the same root cause

Hi developers, I found the following cases should share the same root cause: BUG: unable to handle kernel paging request in bpf_trace_run1 BUG: unable to handle kernel paging request in bpf_trace_run2 BUG: unable to handle kernel paging request in bpf_trace_run3 BUG: unable to handle kernel

"UBSAN: shift-out-of-bounds in mceusb_dev_recv" should share the same root cause with "UBSAN: shift-out-of-bounds in mceusb_dev_printdata"

Hi developers, I found that "UBSAN: shift-out-of-bounds in mceusb_dev_recv" and "UBSAN: shift-out-of-bounds in mceusb_dev_printdata" should share the same root cause. The reason is that the PoCs after minimization has a high similarity with the other. And their stack trace only diverges at the

Re: "general protection fault in sctp_ulpevent_notify_peer_addr_change" and "general protection fault in sctp_ulpevent_nofity_peer_addr_change" should share the same root cause

On Tue, Jan 12, 2021 at 11:27 AM Marcelo Ricardo Leitner wrote: > > On Tue, Jan 12, 2021 at 10:18:00AM +0800, 慕冬亮 wrote: > > Dear developers, > > > > I find that "general protection fault in l2cap_sock_getsockopt" and > > "general protection fa

"general protection fault in sctp_ulpevent_notify_peer_addr_change" and "general protection fault in sctp_ulpevent_nofity_peer_addr_change" should share the same root cause

Dear developers, I find that "general protection fault in l2cap_sock_getsockopt" and "general protection fault in sco_sock_getsockopt" may be duplicated bugs from the same root cause. First, by comparing the PoC similarity after own minimization, we find they share the same PoC. Second, the

Re: general protection fault in reiserfs_security_init

On Monday, September 21, 2020 at 5:32:22 PM UTC+8 syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: 325d0eab Merge branch 'akpm' (patches from Andrew) > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1671c0e390 > kernel config:

WARNING at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset

Hi all, When I leveraged syzkaller to fuzz this kernel image, the VMs is always broken with the following WARNING report: ``` [ 18.093341][T1] [ cut here ] [ 18.093419][T1] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_gem_vram_helper.c:284

Summary of Crash/Panic Behaviors in Linux Kernel

Dear all, Is there any summary of crash/panic behaviors in the Linux Kernel? For example, GPF (general protection fault), Kernel BUG (BUG_ON). -- My best regards to you. No System Is Safe! Dongliang Mu

Re: [PATCH] fix one dead link in ia64/xen.txt

On Tue, Mar 20, 2018 at 4:17 PM, Andrew Cooper wrote: > On 20/03/18 19:56, Dongliang Mu wrote: >> Signed-off-by: Dongliang Mu >> --- >> Documentation/ia64/xen.txt | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git

Re: [PATCH] fix one dead link in ia64/xen.txt

On Tue, Mar 20, 2018 at 4:17 PM, Andrew Cooper wrote: > On 20/03/18 19:56, Dongliang Mu wrote: >> Signed-off-by: Dongliang Mu >> --- >> Documentation/ia64/xen.txt | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/ia64/xen.txt

data structure for NT_386_LTS note entry in coredump

Dear all, I have a question about data structure for NT_386_LTS note entry in coredump and where is the code to store this entry into coredump. When I analyzed coredump and corresponding assembly code, I found there is one memory addressing with gs. GS is a selector used by glibc. But its base

data structure for NT_386_LTS note entry in coredump

Dear all, I have a question about data structure for NT_386_LTS note entry in coredump and where is the code to store this entry into coredump. When I analyzed coredump and corresponding assembly code, I found there is one memory addressing with gs. GS is a selector used by glibc. But its base

Re: error when make pdfdocs

2015-09-25 4:40 GMT+08:00 Jim Davis : > On Fri, Sep 18, 2015 at 7:35 AM, 慕冬亮 wrote: >> I git clone and git pull the latest linux kernel. >> When I make pdfdocs, it reports the following error to me. >> But I checked the filesystems.xml:

Re: error when make pdfdocs

2015-09-25 4:40 GMT+08:00 Jim Davis <jim.ep...@gmail.com>: > On Fri, Sep 18, 2015 at 7:35 AM, 慕冬亮 <mudonglianga...@gmail.com> wrote: >> I git clone and git pull the latest linux kernel. >> When I make pdfdocs, it reports the following error to me. >> But I

[PATCH]Documentation: fix alignment

I don't find any maintainer in the MAINTAINERS who is in charge of this document, so I post it to the lkml. This patch is to fix alignment of one line in Documentation/security/LSM.txt Signed-off-by: Dongliang Mu --- diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt

[PATCH]Documentation: fix alignment

I don't find any maintainer in the MAINTAINERS who is in charge of this document, so I post it to the lkml. This patch is to fix alignment of one line in Documentation/security/LSM.txt Signed-off-by: Dongliang Mu --- diff --git a/Documentation/security/LSM.txt

Re: why is text address constant with full randomization?

2015-09-15 17:05 GMT+08:00 yalin wang : > >> On Sep 15, 2015, at 16:36, 慕冬亮 wrote: >> >> First, my linux kernel is Linux 114-212-83-136 4.1.0-2-amd64. >> Second, I copy /bin/cat in system to mycat , and see the address space >> layout below. >> >>

Re: why is text address constant with full randomization?

2015-09-15 17:05 GMT+08:00 yalin wang <yalin.wang2...@gmail.com>: > >> On Sep 15, 2015, at 16:36, 慕冬亮 <mudonglianga...@gmail.com> wrote: >> >> First, my linux kernel is Linux 114-212-83-136 4.1.0-2-amd64. >> Second, I copy /bin/cat in system to mycat , an

error when make pdfdocs

I git clone and git pull the latest linux kernel. When I make pdfdocs, it reports the following error to me. But I checked the filesystems.xml:14946, no error found. --- PDF

error when make pdfdocs

I git clone and git pull the latest linux kernel. When I make pdfdocs, it reports the following error to me. But I checked the filesystems.xml:14946, no error found. --- PDF

why is text address constant with full randomization?

First, my linux kernel is Linux 114-212-83-136 4.1.0-2-amd64. Second, I copy /bin/cat in system to mycat , and see the address space layout below. mdl@114-212-83-136:~$ ./mycat /proc/self/maps 0040-0040c000 r-xp 08:03 1046776 /home/mdl/mycat 0060b000-0060c000 r--p b000 08:03

why is text address constant with full randomization?

First, my linux kernel is Linux 114-212-83-136 4.1.0-2-amd64. Second, I copy /bin/cat in system to mycat , and see the address space layout below. mdl@114-212-83-136:~$ ./mycat /proc/self/maps 0040-0040c000 r-xp 08:03 1046776 /home/mdl/mycat 0060b000-0060c000 r--p b000 08:03