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 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"
--
My best regards to you.
No System Is Safe!
Dongliang Mu
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 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 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.
Marcelo
On Tue, Jan 12, 2021 at 11:27 AM Marcelo Ricardo Leitner
<[email protected]> 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 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.
> > 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