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
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, “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, “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
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
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
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
14 matches
Mail list logo
