On Tue, Jan 12, 2021 at 11:27 AM Marcelo Ricardo Leitner
[off-list ref] wrote:

On Tue, Jan 12, 2021 at 10:18:00AM +0800, 慕冬亮 wrote:

quoted

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.

I am sorry that the above description is for another bug group -
https://groups.google.com/g/syzkaller-bugs/c/csbAcYWGd2I. I forget to
modify this paragraph. Embarrassing :(

The correct description here should be, "I find that 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, like the title.

quoted

First, by comparing the PoC similarity after own minimization, we find
they share the same PoC. Second, the stack traces for both bug reports
are the same except for the last function. And the different last
functions are due to a function name change (typo fix) from
"sctp_ulpevent_nofity_peer_addr_change" to
"sctp_ulpevent_notify_peer_addr_change"

Not sure where you saw stack traces with this sctp function in it, but
the syzkaller reports from 17 Feb 2020 are not related to SCTP.

The one on sco_sock_getsockopt() seems to be lack of parameter
validation: it doesn't check if optval is big enough when handling
BT_PHY (which has the same value as SCTP_STATUS). It seems also miss a
check on if level != SOL_BLUETOOTH, but I may be wrong here.

l2cap_sock_getsockopt also lacks checking optlen.

Please ignore my mistake, and discuss the issue of
sco/l2tp_sock_getsockopt in the thread - "general protection fault in
l2cap_sock_getsockopt" and "general protection fault in
sco_sock_getsockopt" may share the same root cause
(https://groups.google.com/g/syzkaller-bugs/c/csbAcYWGd2I)

  Marcelo