On Tue, Jan 12, 2021 at 11:27 AM Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx> 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
