On Wed, 09 Feb 2022, Darrick J. Wong wrote:
On Wed, Feb 09, 2022 at 08:52:43AM +0000, Lee Jones wrote:
This reverts commit 60263d5889e6dc5987dc51b801be4955ff2e4aa7.
Reverting since this commit opens a potential avenue for abuse.
What kind of abuse? Did you conclude there's an avenue solely because some combination of userspace rigging produced a BUG warning? Or is this a real problem that someone found?
Genuine question: Is the ability for userspace to crash the kernel not enough to cause concern? I would have thought that we'd want to prevent this.
If by 'real problem' you mean; privilege escalation, memory corruption or data leakage, then no, I haven't found any evidence of that. However, that's not to say these aren't possible as a result of this issue, just that I do not have the skills or knowledge to be able to turn this into a demonstrable attack vector.
However, if you say there is no issue, I'm happy to take your word.
The C-reproducer and more information can be found at the link below.
No. Post the information and your analysis here. I'm not going to dig into some Google site to find out what happened, and I'm not going to assume that future developers will be able to access that URL to learn why this patch was created.
The link provided doesn't contain any further analysis. Only the reproducer and kernel configuration used, which are both too large to enter into a Git commit.
kernel BUG at fs/ext4/inode.c:2647! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 459 Comm: syz-executor359 Tainted: G W 5.10.93-syzkaller-01028-g0347b1658399 #0
What BUG on fs/ext4/inode.c:2647?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/ext...
All I see is a call to pagevec_release()? There's a BUG_ON further up if we wait for page writeback but then it still has Writeback set. But I don't see anything in pagevec_release that would actually result in a BUG warning.
Right, this BUG back-trace was taken from the kernel I received the bug report for. I should have used the one I triggered in Mainline, apologies for that.
The real source of the BUG is in the inlined call to page_buffers().
Here is the link for the latest release kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/ext...
#define page_buffers(page) \ ({ \ BUG_ON(!PagePrivate(page)); \ ((struct buffer_head *)page_private(page)); \ })
Oh, right, this is one of those inscrutable syzkaller things, where a person can spend hours figuring out what the hell it set up.
A link to the config used (again too big to enter into a commit message), can be easily sourced from the link provided.
Yeah...no, you don't get to submit patches to core kernel code, claim it's not your responsibility to know anything about a subsystem that you want to patch, and then expect us to do the work for you. If you pick up a syzkaller report, you get to figure out what broke, why, and how to fix it in a reasonable manner.
You're a maintainer, would you accept a patch like this?
No. I would share my knowledge to provide a helpful review and work with the contributor to find a solution (if applicable).
OH WAIT, you're running this on the Android 5.10 kernel, aren't you? The BUG report came from page_buffers failing to find any buffer heads attached to the page. https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.10-2...
Yes, the H/W I have to prototype these on is a phone and the report that came in was specifically built against the aforementioned kernel.
Yeah, don't care.
"There is nothing to worry about, as it's intended behaviour"?