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
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
smsc95xx_wait
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
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 other
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 i
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,
> > > > USB_VENDOR_REQUEST_IN, offset,
> > >
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 on
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
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 "exit
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 due
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
th
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 due
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 due
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 d
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 lower
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"
(https://syzkaller.appspot.com/bug?id=eea996d785a0f2
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 s
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 appe
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
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 pagin
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 las
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
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 stack
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: ht
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
drm_gem_vram_offset+
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
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 b/Documentation/ia64/xen.t
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 ad
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:
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
i
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.
>>
>>
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 Documentation/DocBook/file
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 1046
33 matches
Mail list logo