[Linux-kernel-mentees] [PATCH] idr: remove WARN_ON_ONCE() when trying to check id

idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
and this happens when syzbot does fuzzing, and that warning is
expected, but WARN_ON_ONCE() is not required here and, cecking
the condition and returning NULL value would be suffice.

Reference: commit b9959c7a347 ("filldir[64]: remove WARN_ON_ONCE() for bad directory entries")
Reported-and-tested-by: syzbot+f7204dcf3df4bb4ce42c@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f7204dcf3df4bb4ce42c 
Signed-off-by: Anmol Karn <redacted>
---
 lib/idr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/idr.c b/lib/idr.c
index 4d2eef0259d2..7c67560c1ecd 100644
--- a/lib/idr.c
+++ b/lib/idr.c

@@ -266,7 +266,7 @@ void *idr_get_next(struct idr *idr, int *nextid)
 	unsigned long id = *nextid;
 	void *entry = idr_get_next_ul(idr, &id);
 
-	if (WARN_ON_ONCE(id > INT_MAX))
+	if (id > INT_MAX)
 		return NULL;
 	*nextid = id;
 	return entry;

-- 
2.28.0

On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:

idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
and this happens when syzbot does fuzzing, and that warning is
expected, but WARN_ON_ONCE() is not required here and, cecking
the condition and returning NULL value would be suffice.

Reference: commit b9959c7a347 ("filldir[64]: remove WARN_ON_ONCE() for bad directory entries")
Reported-and-tested-by: syzbot+f7204dcf3df4bb4ce42c@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f7204dcf3df4bb4ce42c 
Signed-off-by: Anmol Karn <redacted>

https://lore.kernel.org/netdev/20200605120037.17427-1-willy@infradead.org/

On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:

On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:

quoted

idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
and this happens when syzbot does fuzzing, and that warning is
expected, but WARN_ON_ONCE() is not required here and, cecking
the condition and returning NULL value would be suffice.

Reference: commit b9959c7a347 ("filldir[64]: remove WARN_ON_ONCE() for bad directory entries")
Reported-and-tested-by: syzbot+f7204dcf3df4bb4ce42c@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f7204dcf3df4bb4ce42c 
Signed-off-by: Anmol Karn <redacted>

https://lore.kernel.org/netdev/20200605120037.17427-1-willy@infradead.org/

Hello sir,

I have looked into the patch, and it seems the problem is fixed to the root cause
in this patch, but not yet merged due to some backport issues, so, please ignore 
this patch(sent by me), and please let me know if i can contribute to fixing this 
bug's root cause.

Thanks,
Anmol 

On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:

On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:

quoted

On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:

quoted

idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
and this happens when syzbot does fuzzing, and that warning is
expected, but WARN_ON_ONCE() is not required here and, cecking
the condition and returning NULL value would be suffice.

Reference: commit b9959c7a347 ("filldir[64]: remove WARN_ON_ONCE() for bad directory entries")
Reported-and-tested-by: syzbot+f7204dcf3df4bb4ce42c@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f7204dcf3df4bb4ce42c 
Signed-off-by: Anmol Karn <redacted>

https://lore.kernel.org/netdev/20200605120037.17427-1-willy@infradead.org/

Hello sir,

I have looked into the patch, and it seems the problem is fixed to the root cause
in this patch, but not yet merged due to some backport issues, so, please ignore 
this patch(sent by me), and please let me know if i can contribute to fixing this 
bug's root cause.

The root cause is that the network maintainers believe I have a far
greater interest in the qrtr code than I actually do, and the maintainer
of the qrtr code is not doing anything.

On Mon, Sep 14, 2020 at 08:26:55PM +0100, Matthew Wilcox wrote:

On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:

quoted

On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:

quoted

On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:

quoted

idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
and this happens when syzbot does fuzzing, and that warning is
expected, but WARN_ON_ONCE() is not required here and, cecking
the condition and returning NULL value would be suffice.

Reference: commit b9959c7a347 ("filldir[64]: remove WARN_ON_ONCE() for bad directory entries")
Reported-and-tested-by: syzbot+f7204dcf3df4bb4ce42c@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f7204dcf3df4bb4ce42c 
Signed-off-by: Anmol Karn <redacted>

https://lore.kernel.org/netdev/20200605120037.17427-1-willy@infradead.org/

Hello sir,

I have looked into the patch, and it seems the problem is fixed to the root cause
in this patch, but not yet merged due to some backport issues, so, please ignore 
this patch(sent by me), and please let me know if i can contribute to fixing this 
bug's root cause.

The root cause is that the network maintainers believe I have a far
greater interest in the qrtr code than I actually do, and the maintainer
of the qrtr code is not doing anything.

Hello sir,

I hope the patch will get merged soon.

also, i have tried a patch for this bug

Link: https://syzkaller.appspot.com/bug?extid=3b14b2ed9b3d06dcaa07

can you please guide me little how should i proceede with it, and 
also syzbot tested it.  


Thanks,
Anmol

On Tue, Sep 15, 2020 at 10:43:31AM +0530, Anmol Karn wrote:

On Mon, Sep 14, 2020 at 08:26:55PM +0100, Matthew Wilcox wrote:

quoted

On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:

quoted

On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:

quoted

On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:

quoted

idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
and this happens when syzbot does fuzzing, and that warning is
expected, but WARN_ON_ONCE() is not required here and, cecking
the condition and returning NULL value would be suffice.

Reference: commit b9959c7a347 ("filldir[64]: remove WARN_ON_ONCE() for bad directory entries")
Reported-and-tested-by: syzbot+f7204dcf3df4bb4ce42c@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f7204dcf3df4bb4ce42c 
Signed-off-by: Anmol Karn <redacted>

https://lore.kernel.org/netdev/20200605120037.17427-1-willy@infradead.org/

Hello sir,

I have looked into the patch, and it seems the problem is fixed to the root cause
in this patch, but not yet merged due to some backport issues, so, please ignore 
this patch(sent by me), and please let me know if i can contribute to fixing this 
bug's root cause.

The root cause is that the network maintainers believe I have a far
greater interest in the qrtr code than I actually do, and the maintainer
of the qrtr code is not doing anything.

Hello sir,

I hope the patch will get merged soon.

No need to "hope"; you could split up Matthew's patch yourself, and test and
send the resulting patches.  From the above thread, it looks like the networking
developers want one patch to fix the improper use of GFP_ATOMIC (which is the
bug reported by syzbot), and a separate patch to convert qrtr to use the XArray.

also, i have tried a patch for this bug

Link: https://syzkaller.appspot.com/bug?extid=3b14b2ed9b3d06dcaa07

can you please guide me little how should i proceede with it, and 
also syzbot tested it.  

Looks like something timer-related.  You'll need to investigate more, write and
test a fix, and send it to the appropriate kernel mailing lists and developers
(which will probably be different from the ones receiving this current thread).

- Eric

Hello sir,

quoted

I hope the patch will get merged soon.

No need to "hope"; you could split up Matthew's patch yourself, and test and
send the resulting patches.  From the above thread, it looks like the networking
developers want one patch to fix the improper use of GFP_ATOMIC (which is the
bug reported by syzbot), and a separate patch to convert qrtr to use the XArray.

Sure sir I will look into it.

quoted

also, i have tried a patch for this bug

Link: https://syzkaller.appspot.com/bug?extid=3b14b2ed9b3d06dcaa07

can you please guide me little how should i proceede with it, and 
also syzbot tested it.  

Looks like something timer-related.  You'll need to investigate more, write and
test a fix, and send it to the appropriate kernel mailing lists and developers
(which will probably be different from the ones receiving this current thread).

My bad sir, will send it to the appropriate list.

Thanks  
Anmol