Re: general protection fault in send_sigurg_to_task
On Fri, Aug 17, 2018 at 11:22 AM, Eric W. Biederman wrote: > Dmitry Vyukov writes: > >> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman >> wrote: >>> Dmitry Vyukov writes: >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields wrote: > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >> syzbot has found a reproducer for the following crash on: >> >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 >> git tree: linux-next > > I fetched linux-next but don't have 5ed5da74de9e. Hi Bruce, +Stephen for the disappeared linux-next commit. On the dashboard link you can see that it also happened on a more recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see now in linux-next. > I'm also not sure why I'm on the cc for this. You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" as maintainer of the file, which is the file where the crash happened. >>> >>> You need to use your reproducer to bisect and find the commit that >>> caused this. Otherwise you will continue to confuse people. >>> >>> get_maintainer.pl is not a good target for automated reporting >>> especially against linux-next. >> >> Hi Eric, >> >> We will do bisection. >> But I afraid it will not give perfect attribution for a number of reasons: >> - broken build/boot which happens sometimes for prolonged periods and >> prohibits bisection >> - elusive races that can't be reproduced reliably and thus bisection >> can give wrong results >> - bugs introduced too long ago (e.g. author email is not even valid today) >> - reproducers triggering more than 1 bug, so base bisection commit >> can actually be for another bug, or bisection can switch from one bug >> to another >> - last but not least, bugs without reproducers >> Bisection will add useful information to the bug report, but it will >> not necessary make attribution better than it is now. >> >> Do you have more examples where bugs were misreported? From what I see >> current attrition works well. There are episodic fallouts, but well, >> nothing is perfect in this world. Humans don't bisect frequently and >> misreport sometimes. I think we just need to re-route bugs in such >> cases. > > I have yet to see syzbot make a good report. Especially against > linux-next. Well, first of all, we are not aware of any massive problems because nobody tells us. What are the systematic problems that affect lots of reports? I took few recent ones. Anything wrong with them? https://lkml.org/lkml/2018/7/15/230 https://lkml.org/lkml/2018/7/18/992 https://lkml.org/lkml/2018/4/19/705 https://groups.google.com/forum/#!msg/syzkaller-bugs/F7KnbAmMa7E/VSbaYHyQCAAJ
Re: general protection fault in send_sigurg_to_task
On Fri, Aug 17, 2018 at 11:22 AM, Eric W. Biederman wrote: > Dmitry Vyukov writes: > >> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman >> wrote: >>> Dmitry Vyukov writes: >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields wrote: > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >> syzbot has found a reproducer for the following crash on: >> >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 >> git tree: linux-next > > I fetched linux-next but don't have 5ed5da74de9e. Hi Bruce, +Stephen for the disappeared linux-next commit. On the dashboard link you can see that it also happened on a more recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see now in linux-next. > I'm also not sure why I'm on the cc for this. You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" as maintainer of the file, which is the file where the crash happened. >>> >>> You need to use your reproducer to bisect and find the commit that >>> caused this. Otherwise you will continue to confuse people. >>> >>> get_maintainer.pl is not a good target for automated reporting >>> especially against linux-next. >> >> Hi Eric, >> >> We will do bisection. >> But I afraid it will not give perfect attribution for a number of reasons: >> - broken build/boot which happens sometimes for prolonged periods and >> prohibits bisection >> - elusive races that can't be reproduced reliably and thus bisection >> can give wrong results >> - bugs introduced too long ago (e.g. author email is not even valid today) >> - reproducers triggering more than 1 bug, so base bisection commit >> can actually be for another bug, or bisection can switch from one bug >> to another >> - last but not least, bugs without reproducers >> Bisection will add useful information to the bug report, but it will >> not necessary make attribution better than it is now. >> >> Do you have more examples where bugs were misreported? From what I see >> current attrition works well. There are episodic fallouts, but well, >> nothing is perfect in this world. Humans don't bisect frequently and >> misreport sometimes. I think we just need to re-route bugs in such >> cases. > > I have yet to see syzbot make a good report. Especially against > linux-next. Well, first of all, we are not aware of any massive problems because nobody tells us. What are the systematic problems that affect lots of reports? I took few recent ones. Anything wrong with them? https://lkml.org/lkml/2018/7/15/230 https://lkml.org/lkml/2018/7/18/992 https://lkml.org/lkml/2018/4/19/705 https://groups.google.com/forum/#!msg/syzkaller-bugs/F7KnbAmMa7E/VSbaYHyQCAAJ
Re: general protection fault in send_sigurg_to_task
On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote: > Dmitry Vyukov writes: > > > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman > > wrote: > >> Dmitry Vyukov writes: > >> > >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > >>> wrote: > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > > syzbot has found a reproducer for the following crash on: > > > > HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > > git tree: linux-next > > I fetched linux-next but don't have 5ed5da74de9e. > >>> > >>> Hi Bruce, > >>> > >>> +Stephen for the disappeared linux-next commit. > >>> > >>> On the dashboard link you can see that it also happened on a more > >>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > >>> now in linux-next. > >>> > I'm also not sure why I'm on the cc for this. > >>> > >>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" > >>> as maintainer of the file, which is the file where the crash happened. > >> > >> You need to use your reproducer to bisect and find the commit that > >> caused this. Otherwise you will continue to confuse people. > >> > >> get_maintainer.pl is not a good target for automated reporting > >> especially against linux-next. > > > > Hi Eric, > > > > We will do bisection. > > But I afraid it will not give perfect attribution for a number of reasons: > > - broken build/boot which happens sometimes for prolonged periods and > > prohibits bisection > > - elusive races that can't be reproduced reliably and thus bisection > > can give wrong results > > - bugs introduced too long ago (e.g. author email is not even valid today) > > - reproducers triggering more than 1 bug, so base bisection commit > > can actually be for another bug, or bisection can switch from one bug > > to another > > - last but not least, bugs without reproducers > > Bisection will add useful information to the bug report, but it will > > not necessary make attribution better than it is now. > > > > Do you have more examples where bugs were misreported? From what I see > > current attrition works well. There are episodic fallouts, but well, > > nothing is perfect in this world. Humans don't bisect frequently and > > misreport sometimes. I think we just need to re-route bugs in such > > cases. > > I have yet to see syzbot make a good report. Especially against > linux-next. It did result in a fix (thanks!): https://lkml.org/lkml/2018/8/16/47 So I'd call that a better-than-nothing report if not a great report? There's some value just in timeliness; it's a lot easier for me to fix a bug that I introduced in the last few days, with the change still fresh in my mind --b.
Re: general protection fault in send_sigurg_to_task
On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote: > Dmitry Vyukov writes: > > > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman > > wrote: > >> Dmitry Vyukov writes: > >> > >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > >>> wrote: > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > > syzbot has found a reproducer for the following crash on: > > > > HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > > git tree: linux-next > > I fetched linux-next but don't have 5ed5da74de9e. > >>> > >>> Hi Bruce, > >>> > >>> +Stephen for the disappeared linux-next commit. > >>> > >>> On the dashboard link you can see that it also happened on a more > >>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > >>> now in linux-next. > >>> > I'm also not sure why I'm on the cc for this. > >>> > >>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" > >>> as maintainer of the file, which is the file where the crash happened. > >> > >> You need to use your reproducer to bisect and find the commit that > >> caused this. Otherwise you will continue to confuse people. > >> > >> get_maintainer.pl is not a good target for automated reporting > >> especially against linux-next. > > > > Hi Eric, > > > > We will do bisection. > > But I afraid it will not give perfect attribution for a number of reasons: > > - broken build/boot which happens sometimes for prolonged periods and > > prohibits bisection > > - elusive races that can't be reproduced reliably and thus bisection > > can give wrong results > > - bugs introduced too long ago (e.g. author email is not even valid today) > > - reproducers triggering more than 1 bug, so base bisection commit > > can actually be for another bug, or bisection can switch from one bug > > to another > > - last but not least, bugs without reproducers > > Bisection will add useful information to the bug report, but it will > > not necessary make attribution better than it is now. > > > > Do you have more examples where bugs were misreported? From what I see > > current attrition works well. There are episodic fallouts, but well, > > nothing is perfect in this world. Humans don't bisect frequently and > > misreport sometimes. I think we just need to re-route bugs in such > > cases. > > I have yet to see syzbot make a good report. Especially against > linux-next. It did result in a fix (thanks!): https://lkml.org/lkml/2018/8/16/47 So I'd call that a better-than-nothing report if not a great report? There's some value just in timeliness; it's a lot easier for me to fix a bug that I introduced in the last few days, with the change still fresh in my mind --b.
Re: general protection fault in send_sigurg_to_task
Dmitry Vyukov writes: > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman > wrote: >> Dmitry Vyukov writes: >> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields >>> wrote: On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > git tree: linux-next I fetched linux-next but don't have 5ed5da74de9e. >>> >>> Hi Bruce, >>> >>> +Stephen for the disappeared linux-next commit. >>> >>> On the dashboard link you can see that it also happened on a more >>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see >>> now in linux-next. >>> I'm also not sure why I'm on the cc for this. >>> >>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" >>> as maintainer of the file, which is the file where the crash happened. >> >> You need to use your reproducer to bisect and find the commit that >> caused this. Otherwise you will continue to confuse people. >> >> get_maintainer.pl is not a good target for automated reporting >> especially against linux-next. > > Hi Eric, > > We will do bisection. > But I afraid it will not give perfect attribution for a number of reasons: > - broken build/boot which happens sometimes for prolonged periods and > prohibits bisection > - elusive races that can't be reproduced reliably and thus bisection > can give wrong results > - bugs introduced too long ago (e.g. author email is not even valid today) > - reproducers triggering more than 1 bug, so base bisection commit > can actually be for another bug, or bisection can switch from one bug > to another > - last but not least, bugs without reproducers > Bisection will add useful information to the bug report, but it will > not necessary make attribution better than it is now. > > Do you have more examples where bugs were misreported? From what I see > current attrition works well. There are episodic fallouts, but well, > nothing is perfect in this world. Humans don't bisect frequently and > misreport sometimes. I think we just need to re-route bugs in such > cases. I have yet to see syzbot make a good report. Especially against linux-next. Eric
Re: general protection fault in send_sigurg_to_task
Dmitry Vyukov writes: > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman > wrote: >> Dmitry Vyukov writes: >> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields >>> wrote: On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > git tree: linux-next I fetched linux-next but don't have 5ed5da74de9e. >>> >>> Hi Bruce, >>> >>> +Stephen for the disappeared linux-next commit. >>> >>> On the dashboard link you can see that it also happened on a more >>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see >>> now in linux-next. >>> I'm also not sure why I'm on the cc for this. >>> >>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" >>> as maintainer of the file, which is the file where the crash happened. >> >> You need to use your reproducer to bisect and find the commit that >> caused this. Otherwise you will continue to confuse people. >> >> get_maintainer.pl is not a good target for automated reporting >> especially against linux-next. > > Hi Eric, > > We will do bisection. > But I afraid it will not give perfect attribution for a number of reasons: > - broken build/boot which happens sometimes for prolonged periods and > prohibits bisection > - elusive races that can't be reproduced reliably and thus bisection > can give wrong results > - bugs introduced too long ago (e.g. author email is not even valid today) > - reproducers triggering more than 1 bug, so base bisection commit > can actually be for another bug, or bisection can switch from one bug > to another > - last but not least, bugs without reproducers > Bisection will add useful information to the bug report, but it will > not necessary make attribution better than it is now. > > Do you have more examples where bugs were misreported? From what I see > current attrition works well. There are episodic fallouts, but well, > nothing is perfect in this world. Humans don't bisect frequently and > misreport sometimes. I think we just need to re-route bugs in such > cases. I have yet to see syzbot make a good report. Especially against linux-next. Eric
Re: general protection fault in send_sigurg_to_task
On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman wrote: > Dmitry Vyukov writes: > >> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields >> wrote: >>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: syzbot has found a reproducer for the following crash on: HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 git tree: linux-next >>> >>> I fetched linux-next but don't have 5ed5da74de9e. >> >> Hi Bruce, >> >> +Stephen for the disappeared linux-next commit. >> >> On the dashboard link you can see that it also happened on a more >> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see >> now in linux-next. >> >>> I'm also not sure why I'm on the cc for this. >> >> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" >> as maintainer of the file, which is the file where the crash happened. > > You need to use your reproducer to bisect and find the commit that > caused this. Otherwise you will continue to confuse people. > > get_maintainer.pl is not a good target for automated reporting > especially against linux-next. Hi Eric, We will do bisection. But I afraid it will not give perfect attribution for a number of reasons: - broken build/boot which happens sometimes for prolonged periods and prohibits bisection - elusive races that can't be reproduced reliably and thus bisection can give wrong results - bugs introduced too long ago (e.g. author email is not even valid today) - reproducers triggering more than 1 bug, so base bisection commit can actually be for another bug, or bisection can switch from one bug to another - last but not least, bugs without reproducers Bisection will add useful information to the bug report, but it will not necessary make attribution better than it is now. Do you have more examples where bugs were misreported? From what I see current attrition works well. There are episodic fallouts, but well, nothing is perfect in this world. Humans don't bisect frequently and misreport sometimes. I think we just need to re-route bugs in such cases.
Re: general protection fault in send_sigurg_to_task
On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman wrote: > Dmitry Vyukov writes: > >> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields >> wrote: >>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: syzbot has found a reproducer for the following crash on: HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 git tree: linux-next >>> >>> I fetched linux-next but don't have 5ed5da74de9e. >> >> Hi Bruce, >> >> +Stephen for the disappeared linux-next commit. >> >> On the dashboard link you can see that it also happened on a more >> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see >> now in linux-next. >> >>> I'm also not sure why I'm on the cc for this. >> >> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" >> as maintainer of the file, which is the file where the crash happened. > > You need to use your reproducer to bisect and find the commit that > caused this. Otherwise you will continue to confuse people. > > get_maintainer.pl is not a good target for automated reporting > especially against linux-next. Hi Eric, We will do bisection. But I afraid it will not give perfect attribution for a number of reasons: - broken build/boot which happens sometimes for prolonged periods and prohibits bisection - elusive races that can't be reproduced reliably and thus bisection can give wrong results - bugs introduced too long ago (e.g. author email is not even valid today) - reproducers triggering more than 1 bug, so base bisection commit can actually be for another bug, or bisection can switch from one bug to another - last but not least, bugs without reproducers Bisection will add useful information to the bug report, but it will not necessary make attribution better than it is now. Do you have more examples where bugs were misreported? From what I see current attrition works well. There are episodic fallouts, but well, nothing is perfect in this world. Humans don't bisect frequently and misreport sometimes. I think we just need to re-route bugs in such cases.
Re: general protection fault in send_sigurg_to_task
Dmitry Vyukov writes: > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > wrote: >> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >>> syzbot has found a reproducer for the following crash on: >>> >>> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 >>> git tree: linux-next >> >> I fetched linux-next but don't have 5ed5da74de9e. > > Hi Bruce, > > +Stephen for the disappeared linux-next commit. > > On the dashboard link you can see that it also happened on a more > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > now in linux-next. > >> I'm also not sure why I'm on the cc for this. > > You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" > as maintainer of the file, which is the file where the crash happened. You need to use your reproducer to bisect and find the commit that caused this. Otherwise you will continue to confuse people. get_maintainer.pl is not a good target for automated reporting especially against linux-next. Eric
Re: general protection fault in send_sigurg_to_task
Dmitry Vyukov writes: > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > wrote: >> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >>> syzbot has found a reproducer for the following crash on: >>> >>> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 >>> git tree: linux-next >> >> I fetched linux-next but don't have 5ed5da74de9e. > > Hi Bruce, > > +Stephen for the disappeared linux-next commit. > > On the dashboard link you can see that it also happened on a more > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > now in linux-next. > >> I'm also not sure why I'm on the cc for this. > > You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" > as maintainer of the file, which is the file where the crash happened. You need to use your reproducer to bisect and find the commit that caused this. Otherwise you will continue to confuse people. get_maintainer.pl is not a good target for automated reporting especially against linux-next. Eric
Re: general protection fault in send_sigurg_to_task
On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote: > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > wrote: > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > >> syzbot has found a reproducer for the following crash on: > >> > >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > >> git tree: linux-next > > > > I fetched linux-next but don't have 5ed5da74de9e. > > Hi Bruce, > > +Stephen for the disappeared linux-next commit. > > On the dashboard link you can see that it also happened on a more > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > now in linux-next. > > > I'm also not sure why I'm on the cc for this. > > You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" > as maintainer of the file, which is the file where the crash happened. We should probably fix that. There's a tiny bit of lock-related code in that file but it's not at all interesting compared, say, to the code that this bug is hitting (Which I have no clue about. send_sigurg_to_task() is getting a bad task? Help.) --b. diff --git a/MAINTAINERS b/MAINTAINERS index 9d5eeff51b5f..a5dca2be8513 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5541,9 +5541,6 @@ M:Jeff Layton M: "J. Bruce Fields" L: linux-fsde...@vger.kernel.org S: Maintained -F: include/linux/fcntl.h -F: include/uapi/linux/fcntl.h -F: fs/fcntl.c F: fs/locks.c FILESYSTEMS (VFS and infrastructure)
Re: general protection fault in send_sigurg_to_task
On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote: > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > wrote: > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > >> syzbot has found a reproducer for the following crash on: > >> > >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > >> git tree: linux-next > > > > I fetched linux-next but don't have 5ed5da74de9e. > > Hi Bruce, > > +Stephen for the disappeared linux-next commit. > > On the dashboard link you can see that it also happened on a more > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > now in linux-next. > > > I'm also not sure why I'm on the cc for this. > > You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" > as maintainer of the file, which is the file where the crash happened. We should probably fix that. There's a tiny bit of lock-related code in that file but it's not at all interesting compared, say, to the code that this bug is hitting (Which I have no clue about. send_sigurg_to_task() is getting a bad task? Help.) --b. diff --git a/MAINTAINERS b/MAINTAINERS index 9d5eeff51b5f..a5dca2be8513 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5541,9 +5541,6 @@ M:Jeff Layton M: "J. Bruce Fields" L: linux-fsde...@vger.kernel.org S: Maintained -F: include/linux/fcntl.h -F: include/uapi/linux/fcntl.h -F: fs/fcntl.c F: fs/locks.c FILESYSTEMS (VFS and infrastructure)
Re: general protection fault in send_sigurg_to_task
On Wed, Aug 15, 2018 at 10:11:20AM +1000, Stephen Rothwell wrote: > Hi Bruce, > > On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov wrote: > > > > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > > wrote: > > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > > >> syzbot has found a reproducer for the following crash on: > > >> > > >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > > >> git tree: linux-next > > > > > > I fetched linux-next but don't have 5ed5da74de9e. > > > > +Stephen for the disappeared linux-next commit. > > That is just the HEAD commit on linux-next that day. If you fetched > linux-next after I released next-20180814 yesterday, then it would have > a different HEAD commit. If you check out the tag next-20180813, you > will get the above HEAD commit. > > > On the dashboard link you can see that it also happened on a more > > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > > now in linux-next. > > Which is just the HEAD commit of next-20180814. > > Linux-next is rebuilt every day based on Linus' tree of the day, > followed by merging all the other branches, so its HEAD is different > every day. I new it was rebuilt every day, but for some reason I expected git to fetch all new tags. But that's wrong, it just fetches whatever branch(es) you request and then only tags that happen to reference stuff on that branch; from git-fetch(1): "By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote..tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well." Sorry for the confusion! --b.
Re: general protection fault in send_sigurg_to_task
On Wed, Aug 15, 2018 at 10:11:20AM +1000, Stephen Rothwell wrote: > Hi Bruce, > > On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov wrote: > > > > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > > wrote: > > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > > >> syzbot has found a reproducer for the following crash on: > > >> > > >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > > >> git tree: linux-next > > > > > > I fetched linux-next but don't have 5ed5da74de9e. > > > > +Stephen for the disappeared linux-next commit. > > That is just the HEAD commit on linux-next that day. If you fetched > linux-next after I released next-20180814 yesterday, then it would have > a different HEAD commit. If you check out the tag next-20180813, you > will get the above HEAD commit. > > > On the dashboard link you can see that it also happened on a more > > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > > now in linux-next. > > Which is just the HEAD commit of next-20180814. > > Linux-next is rebuilt every day based on Linus' tree of the day, > followed by merging all the other branches, so its HEAD is different > every day. I new it was rebuilt every day, but for some reason I expected git to fetch all new tags. But that's wrong, it just fetches whatever branch(es) you request and then only tags that happen to reference stuff on that branch; from git-fetch(1): "By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote..tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well." Sorry for the confusion! --b.
Re: general protection fault in send_sigurg_to_task
Hi Bruce, On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov wrote: > > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > wrote: > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > >> syzbot has found a reproducer for the following crash on: > >> > >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > >> git tree: linux-next > > > > I fetched linux-next but don't have 5ed5da74de9e. > > +Stephen for the disappeared linux-next commit. That is just the HEAD commit on linux-next that day. If you fetched linux-next after I released next-20180814 yesterday, then it would have a different HEAD commit. If you check out the tag next-20180813, you will get the above HEAD commit. > On the dashboard link you can see that it also happened on a more > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > now in linux-next. Which is just the HEAD commit of next-20180814. Linux-next is rebuilt every day based on Linus' tree of the day, followed by merging all the other branches, so its HEAD is different every day. -- Cheers, Stephen Rothwell pgpaplQCyIbqo.pgp Description: OpenPGP digital signature
Re: general protection fault in send_sigurg_to_task
Hi Bruce, On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov wrote: > > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields > wrote: > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > >> syzbot has found a reproducer for the following crash on: > >> > >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > >> git tree: linux-next > > > > I fetched linux-next but don't have 5ed5da74de9e. > > +Stephen for the disappeared linux-next commit. That is just the HEAD commit on linux-next that day. If you fetched linux-next after I released next-20180814 yesterday, then it would have a different HEAD commit. If you check out the tag next-20180813, you will get the above HEAD commit. > On the dashboard link you can see that it also happened on a more > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > now in linux-next. Which is just the HEAD commit of next-20180814. Linux-next is rebuilt every day based on Linus' tree of the day, followed by merging all the other branches, so its HEAD is different every day. -- Cheers, Stephen Rothwell pgpaplQCyIbqo.pgp Description: OpenPGP digital signature
Re: general protection fault in send_sigurg_to_task
On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields wrote: > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >> syzbot has found a reproducer for the following crash on: >> >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 >> git tree: linux-next > > I fetched linux-next but don't have 5ed5da74de9e. Hi Bruce, +Stephen for the disappeared linux-next commit. On the dashboard link you can see that it also happened on a more recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see now in linux-next. > I'm also not sure why I'm on the cc for this. You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" as maintainer of the file, which is the file where the crash happened. > --b. > >> console output: https://syzkaller.appspot.com/x/log.txt?x=1078702840 >> kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab >> dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761 >> compiler: gcc (GCC) 8.0.1 20180413 (experimental) >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e82840 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15084b7240 >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit: >> Reported-by: syzbot+1f371ca19b341a276...@syzkaller.appspotmail.com >> >> nf_conntrack: default automatic helper assignment has been turned >> off for security reasons and CT-based firewall rule not found. Use >> the iptables CT target to attach helpers instead. >> kasan: CONFIG_KASAN_INLINE enabled >> kasan: GPF could be caused by NULL-ptr deref or user memory access >> general protection fault: [#1] SMP KASAN >> CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37 >> Hardware name: Google Google Compute Engine/Google Compute Engine, >> BIOS Google 01/01/2011 >> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] >> RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] >> RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 >> Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf >> 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> >> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 >> RSP: :8801db106c18 EFLAGS: 00010202 >> RAX: dc00 RBX: 8801db106c88 RCX: 81cae2d0 >> RDX: 00cb RSI: 81cadf6d RDI: 0658 >> RBP: 8801db106cb0 R08: 8801b4ad4640 R09: ed003b6246d6 >> R10: ed003b6246d6 R11: 8801db1236b3 R12: 11003b620d85 >> R13: 8801b4cb9388 R14: 0001 R15: >> FS: 00949880() GS:8801db10() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 00400bc3 CR3: 0001bb122000 CR4: 001406e0 >> Call Trace: >> >> send_sigurg+0x342/0x480 fs/fcntl.c:833 >> sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731 >> tcp_check_urg net/ipv4/tcp_input.c:5266 [inline] >> tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307 >> tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637 >> tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532 >> tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824 >> ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215 >> NF_HOOK include/linux/netfilter.h:287 [inline] >> ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256 >> dst_input include/net/dst.h:450 [inline] >> ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415 >> NF_HOOK include/linux/netfilter.h:287 [inline] >> ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524 >> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892 >> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002 >> process_backlog+0x219/0x760 net/core/dev.c:5808 >> napi_poll net/core/dev.c:6228 [inline] >> net_rx_action+0x799/0x1900 net/core/dev.c:6294 >> __do_softirq+0x2e8/0xa6d kernel/softirq.c:292 >> invoke_softirq kernel/softirq.c:372 [inline] >> irq_exit+0x1d4/0x210 kernel/softirq.c:412 >> exiting_irq arch/x86/include/asm/apic.h:527 [inline] >> smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055 >> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867 >> >> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 >> [inline] >> RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941 >> Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 >> 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> >> 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4 >> RSP: :8801c6de7578 EFLAGS: 0286 ORIG_RAX: ff13 >> RAX: dc00 RBX: 0286 RCX: >> RDX: 10fe3665 RSI: RDI: 0286 >> RBP: 8801c6de7598 R08: ed003b6246d7 R09: ed003b6246d6 >> R10: ed003b6246d6 R11: 8801db1236b3 R12: 8801b4ad4640 >> R13: 0001 R14: dc00 R15:
Re: general protection fault in send_sigurg_to_task
On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields wrote: > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >> syzbot has found a reproducer for the following crash on: >> >> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 >> git tree: linux-next > > I fetched linux-next but don't have 5ed5da74de9e. Hi Bruce, +Stephen for the disappeared linux-next commit. On the dashboard link you can see that it also happened on a more recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see now in linux-next. > I'm also not sure why I'm on the cc for this. You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" as maintainer of the file, which is the file where the crash happened. > --b. > >> console output: https://syzkaller.appspot.com/x/log.txt?x=1078702840 >> kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab >> dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761 >> compiler: gcc (GCC) 8.0.1 20180413 (experimental) >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e82840 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15084b7240 >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit: >> Reported-by: syzbot+1f371ca19b341a276...@syzkaller.appspotmail.com >> >> nf_conntrack: default automatic helper assignment has been turned >> off for security reasons and CT-based firewall rule not found. Use >> the iptables CT target to attach helpers instead. >> kasan: CONFIG_KASAN_INLINE enabled >> kasan: GPF could be caused by NULL-ptr deref or user memory access >> general protection fault: [#1] SMP KASAN >> CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37 >> Hardware name: Google Google Compute Engine/Google Compute Engine, >> BIOS Google 01/01/2011 >> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] >> RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] >> RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 >> Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf >> 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> >> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 >> RSP: :8801db106c18 EFLAGS: 00010202 >> RAX: dc00 RBX: 8801db106c88 RCX: 81cae2d0 >> RDX: 00cb RSI: 81cadf6d RDI: 0658 >> RBP: 8801db106cb0 R08: 8801b4ad4640 R09: ed003b6246d6 >> R10: ed003b6246d6 R11: 8801db1236b3 R12: 11003b620d85 >> R13: 8801b4cb9388 R14: 0001 R15: >> FS: 00949880() GS:8801db10() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 00400bc3 CR3: 0001bb122000 CR4: 001406e0 >> Call Trace: >> >> send_sigurg+0x342/0x480 fs/fcntl.c:833 >> sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731 >> tcp_check_urg net/ipv4/tcp_input.c:5266 [inline] >> tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307 >> tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637 >> tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532 >> tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824 >> ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215 >> NF_HOOK include/linux/netfilter.h:287 [inline] >> ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256 >> dst_input include/net/dst.h:450 [inline] >> ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415 >> NF_HOOK include/linux/netfilter.h:287 [inline] >> ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524 >> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892 >> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002 >> process_backlog+0x219/0x760 net/core/dev.c:5808 >> napi_poll net/core/dev.c:6228 [inline] >> net_rx_action+0x799/0x1900 net/core/dev.c:6294 >> __do_softirq+0x2e8/0xa6d kernel/softirq.c:292 >> invoke_softirq kernel/softirq.c:372 [inline] >> irq_exit+0x1d4/0x210 kernel/softirq.c:412 >> exiting_irq arch/x86/include/asm/apic.h:527 [inline] >> smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055 >> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867 >> >> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 >> [inline] >> RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941 >> Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 >> 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> >> 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4 >> RSP: :8801c6de7578 EFLAGS: 0286 ORIG_RAX: ff13 >> RAX: dc00 RBX: 0286 RCX: >> RDX: 10fe3665 RSI: RDI: 0286 >> RBP: 8801c6de7598 R08: ed003b6246d7 R09: ed003b6246d6 >> R10: ed003b6246d6 R11: 8801db1236b3 R12: 8801b4ad4640 >> R13: 0001 R14: dc00 R15:
Re: general protection fault in send_sigurg_to_task
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > git tree: linux-next I fetched linux-next but don't have 5ed5da74de9e. I'm also not sure why I'm on the cc for this. --b. > console output: https://syzkaller.appspot.com/x/log.txt?x=1078702840 > kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab > dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e82840 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15084b7240 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+1f371ca19b341a276...@syzkaller.appspotmail.com > > nf_conntrack: default automatic helper assignment has been turned > off for security reasons and CT-based firewall rule not found. Use > the iptables CT target to attach helpers instead. > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN > CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37 > Hardware name: Google Google Compute Engine/Google Compute Engine, > BIOS Google 01/01/2011 > RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] > RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] > RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 > Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf > 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> > 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 > RSP: :8801db106c18 EFLAGS: 00010202 > RAX: dc00 RBX: 8801db106c88 RCX: 81cae2d0 > RDX: 00cb RSI: 81cadf6d RDI: 0658 > RBP: 8801db106cb0 R08: 8801b4ad4640 R09: ed003b6246d6 > R10: ed003b6246d6 R11: 8801db1236b3 R12: 11003b620d85 > R13: 8801b4cb9388 R14: 0001 R15: > FS: 00949880() GS:8801db10() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 00400bc3 CR3: 0001bb122000 CR4: 001406e0 > Call Trace: > > send_sigurg+0x342/0x480 fs/fcntl.c:833 > sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731 > tcp_check_urg net/ipv4/tcp_input.c:5266 [inline] > tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307 > tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637 > tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532 > tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824 > ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215 > NF_HOOK include/linux/netfilter.h:287 [inline] > ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256 > dst_input include/net/dst.h:450 [inline] > ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415 > NF_HOOK include/linux/netfilter.h:287 [inline] > ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524 > __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892 > __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002 > process_backlog+0x219/0x760 net/core/dev.c:5808 > napi_poll net/core/dev.c:6228 [inline] > net_rx_action+0x799/0x1900 net/core/dev.c:6294 > __do_softirq+0x2e8/0xa6d kernel/softirq.c:292 > invoke_softirq kernel/softirq.c:372 [inline] > irq_exit+0x1d4/0x210 kernel/softirq.c:412 > exiting_irq arch/x86/include/asm/apic.h:527 [inline] > smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867 > > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 > [inline] > RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941 > Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 > 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> > 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4 > RSP: :8801c6de7578 EFLAGS: 0286 ORIG_RAX: ff13 > RAX: dc00 RBX: 0286 RCX: > RDX: 10fe3665 RSI: RDI: 0286 > RBP: 8801c6de7598 R08: ed003b6246d7 R09: ed003b6246d6 > R10: ed003b6246d6 R11: 8801db1236b3 R12: 8801b4ad4640 > R13: 0001 R14: dc00 R15: > lock_is_held include/linux/lockdep.h:344 [inline] > rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285 > xa_entry include/linux/xarray.h:486 [inline] > xas_next_entry include/linux/xarray.h:905 [inline] > filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536 > do_fault_around mm/memory.c:3603 [inline] > do_read_fault mm/memory.c:3637 [inline] > do_fault mm/memory.c:3742 [inline] > handle_pte_fault mm/memory.c:3973 [inline] > __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097
Re: general protection fault in send_sigurg_to_task
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 > git tree: linux-next I fetched linux-next but don't have 5ed5da74de9e. I'm also not sure why I'm on the cc for this. --b. > console output: https://syzkaller.appspot.com/x/log.txt?x=1078702840 > kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab > dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e82840 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15084b7240 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+1f371ca19b341a276...@syzkaller.appspotmail.com > > nf_conntrack: default automatic helper assignment has been turned > off for security reasons and CT-based firewall rule not found. Use > the iptables CT target to attach helpers instead. > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN > CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37 > Hardware name: Google Google Compute Engine/Google Compute Engine, > BIOS Google 01/01/2011 > RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] > RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] > RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 > Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf > 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> > 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 > RSP: :8801db106c18 EFLAGS: 00010202 > RAX: dc00 RBX: 8801db106c88 RCX: 81cae2d0 > RDX: 00cb RSI: 81cadf6d RDI: 0658 > RBP: 8801db106cb0 R08: 8801b4ad4640 R09: ed003b6246d6 > R10: ed003b6246d6 R11: 8801db1236b3 R12: 11003b620d85 > R13: 8801b4cb9388 R14: 0001 R15: > FS: 00949880() GS:8801db10() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 00400bc3 CR3: 0001bb122000 CR4: 001406e0 > Call Trace: > > send_sigurg+0x342/0x480 fs/fcntl.c:833 > sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731 > tcp_check_urg net/ipv4/tcp_input.c:5266 [inline] > tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307 > tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637 > tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532 > tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824 > ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215 > NF_HOOK include/linux/netfilter.h:287 [inline] > ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256 > dst_input include/net/dst.h:450 [inline] > ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415 > NF_HOOK include/linux/netfilter.h:287 [inline] > ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524 > __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892 > __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002 > process_backlog+0x219/0x760 net/core/dev.c:5808 > napi_poll net/core/dev.c:6228 [inline] > net_rx_action+0x799/0x1900 net/core/dev.c:6294 > __do_softirq+0x2e8/0xa6d kernel/softirq.c:292 > invoke_softirq kernel/softirq.c:372 [inline] > irq_exit+0x1d4/0x210 kernel/softirq.c:412 > exiting_irq arch/x86/include/asm/apic.h:527 [inline] > smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867 > > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 > [inline] > RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941 > Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 > 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> > 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4 > RSP: :8801c6de7578 EFLAGS: 0286 ORIG_RAX: ff13 > RAX: dc00 RBX: 0286 RCX: > RDX: 10fe3665 RSI: RDI: 0286 > RBP: 8801c6de7598 R08: ed003b6246d7 R09: ed003b6246d6 > R10: ed003b6246d6 R11: 8801db1236b3 R12: 8801b4ad4640 > R13: 0001 R14: dc00 R15: > lock_is_held include/linux/lockdep.h:344 [inline] > rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285 > xa_entry include/linux/xarray.h:486 [inline] > xas_next_entry include/linux/xarray.h:905 [inline] > filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536 > do_fault_around mm/memory.c:3603 [inline] > do_read_fault mm/memory.c:3637 [inline] > do_fault mm/memory.c:3742 [inline] > handle_pte_fault mm/memory.c:3973 [inline] > __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097
Re: general protection fault in send_sigurg_to_task
syzbot has found a reproducer for the following crash on: HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1078702840 kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e82840 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15084b7240 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1f371ca19b341a276...@syzkaller.appspotmail.com nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 RSP: :8801db106c18 EFLAGS: 00010202 RAX: dc00 RBX: 8801db106c88 RCX: 81cae2d0 RDX: 00cb RSI: 81cadf6d RDI: 0658 RBP: 8801db106cb0 R08: 8801b4ad4640 R09: ed003b6246d6 R10: ed003b6246d6 R11: 8801db1236b3 R12: 11003b620d85 R13: 8801b4cb9388 R14: 0001 R15: FS: 00949880() GS:8801db10() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00400bc3 CR3: 0001bb122000 CR4: 001406e0 Call Trace: send_sigurg+0x342/0x480 fs/fcntl.c:833 sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731 tcp_check_urg net/ipv4/tcp_input.c:5266 [inline] tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307 tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637 tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532 tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824 ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215 NF_HOOK include/linux/netfilter.h:287 [inline] ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256 dst_input include/net/dst.h:450 [inline] ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415 NF_HOOK include/linux/netfilter.h:287 [inline] ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524 __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002 process_backlog+0x219/0x760 net/core/dev.c:5808 napi_poll net/core/dev.c:6228 [inline] net_rx_action+0x799/0x1900 net/core/dev.c:6294 __do_softirq+0x2e8/0xa6d kernel/softirq.c:292 invoke_softirq kernel/softirq.c:372 [inline] irq_exit+0x1d4/0x210 kernel/softirq.c:412 exiting_irq arch/x86/include/asm/apic.h:527 [inline] smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline] RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941 Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4 RSP: :8801c6de7578 EFLAGS: 0286 ORIG_RAX: ff13 RAX: dc00 RBX: 0286 RCX: RDX: 10fe3665 RSI: RDI: 0286 RBP: 8801c6de7598 R08: ed003b6246d7 R09: ed003b6246d6 R10: ed003b6246d6 R11: 8801db1236b3 R12: 8801b4ad4640 R13: 0001 R14: dc00 R15: lock_is_held include/linux/lockdep.h:344 [inline] rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285 xa_entry include/linux/xarray.h:486 [inline] xas_next_entry include/linux/xarray.h:905 [inline] filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536 do_fault_around mm/memory.c:3603 [inline] do_read_fault mm/memory.c:3637 [inline] do_fault mm/memory.c:3742 [inline] handle_pte_fault mm/memory.c:3973 [inline] __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097 handle_mm_fault+0x53e/0xc80 mm/memory.c:4134 __do_page_fault+0x620/0xe50 arch/x86/mm/fault.c:1395 do_page_fault+0xf6/0x7a4 arch/x86/mm/fault.c:1470 page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1164 RIP: 0033:0x400bc3 Code: 09 00 00 00 e8 0e 09 04 00 48 c7 05 2b 2b 2d 00 00 00 00 00 48 83 c4 10 e8 fa f1 03
Re: general protection fault in send_sigurg_to_task
syzbot has found a reproducer for the following crash on: HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1078702840 kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e82840 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15084b7240 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1f371ca19b341a276...@syzkaller.appspotmail.com nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 RSP: :8801db106c18 EFLAGS: 00010202 RAX: dc00 RBX: 8801db106c88 RCX: 81cae2d0 RDX: 00cb RSI: 81cadf6d RDI: 0658 RBP: 8801db106cb0 R08: 8801b4ad4640 R09: ed003b6246d6 R10: ed003b6246d6 R11: 8801db1236b3 R12: 11003b620d85 R13: 8801b4cb9388 R14: 0001 R15: FS: 00949880() GS:8801db10() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00400bc3 CR3: 0001bb122000 CR4: 001406e0 Call Trace: send_sigurg+0x342/0x480 fs/fcntl.c:833 sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731 tcp_check_urg net/ipv4/tcp_input.c:5266 [inline] tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307 tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637 tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532 tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824 ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215 NF_HOOK include/linux/netfilter.h:287 [inline] ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256 dst_input include/net/dst.h:450 [inline] ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415 NF_HOOK include/linux/netfilter.h:287 [inline] ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524 __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002 process_backlog+0x219/0x760 net/core/dev.c:5808 napi_poll net/core/dev.c:6228 [inline] net_rx_action+0x799/0x1900 net/core/dev.c:6294 __do_softirq+0x2e8/0xa6d kernel/softirq.c:292 invoke_softirq kernel/softirq.c:372 [inline] irq_exit+0x1d4/0x210 kernel/softirq.c:412 exiting_irq arch/x86/include/asm/apic.h:527 [inline] smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline] RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941 Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4 RSP: :8801c6de7578 EFLAGS: 0286 ORIG_RAX: ff13 RAX: dc00 RBX: 0286 RCX: RDX: 10fe3665 RSI: RDI: 0286 RBP: 8801c6de7598 R08: ed003b6246d7 R09: ed003b6246d6 R10: ed003b6246d6 R11: 8801db1236b3 R12: 8801b4ad4640 R13: 0001 R14: dc00 R15: lock_is_held include/linux/lockdep.h:344 [inline] rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285 xa_entry include/linux/xarray.h:486 [inline] xas_next_entry include/linux/xarray.h:905 [inline] filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536 do_fault_around mm/memory.c:3603 [inline] do_read_fault mm/memory.c:3637 [inline] do_fault mm/memory.c:3742 [inline] handle_pte_fault mm/memory.c:3973 [inline] __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097 handle_mm_fault+0x53e/0xc80 mm/memory.c:4134 __do_page_fault+0x620/0xe50 arch/x86/mm/fault.c:1395 do_page_fault+0xf6/0x7a4 arch/x86/mm/fault.c:1470 page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1164 RIP: 0033:0x400bc3 Code: 09 00 00 00 e8 0e 09 04 00 48 c7 05 2b 2b 2d 00 00 00 00 00 48 83 c4 10 e8 fa f1 03
