[Bug] possible deadlock in vfs_rmdir in Linux kernel v6.12

[Bug] possible deadlock in vfs_rmdir in Linux kernel v6.12

[Luka]

Dear Kernel Maintainers,

I am writing to report a potential vulnerability identified in the
upstream Linux Kernel version v6.12, corresponding to the following
commit in the mainline repository:

Git Commit:  adc218676eef25575469234709c2d87185ca223a (tag: v6.12)

This issue was discovered during the testing of the Android 16 AOSP
kernel, which is based on Linux kernel version 6.12, specifically from
the AOSP kernel branch:

AOSP kernel branch: android16-6.12
Manifest path: kernel/common.git
Source URL:  https://android.googlesource.com/kernel/common/+/refs/heads/android16-6.12

Although this kernel branch is used in Android 16 development, its
base is aligned with the upstream Linux v6.12 release. I observed this
issue while conducting stability and fuzzing tests on the Android 16
platform and identified that the root cause lies in the upstream
codebase.


Bug Location: vfs_rmdir+0x118/0x488 fs/namei.c:4329

Bug Report: https://hastebin.com/share/vobatolola.bash

Entire Log: https://hastebin.com/share/efajodumuh.perl


Thank you very much for your time and attention. I sincerely apologize
that I am currently unable to provide a reproducer for this issue.
However, I am actively working on reproducing the problem, and I will
make sure to share any findings or reproducing steps with you as soon
as they are available.

I greatly appreciate your efforts in maintaining the Linux kernel and
your attention to this matter.

Best regards,
Luka

[Bug] kernel BUG in may_delete in linux kernel v6.12

[Luka]

Dear Kernel Maintainers,

I am writing to report a potential vulnerability identified in the
upstream Linux Kernel version v6.12, corresponding to the following
commit in the mainline repository:

Git Commit:  adc218676eef25575469234709c2d87185ca223a (tag: v6.12)

This issue was discovered during the testing of the Android 16 AOSP
kernel, which is based on Linux kernel version 6.12, specifically from
the AOSP kernel branch:

AOSP kernel branch: android16-6.12
Manifest path: kernel/common.git
Source URL:  https://android.googlesource.com/kernel/common/+/refs/heads/android16-6.12

Although this kernel branch is used in Android 16 development, its
base is aligned with the upstream Linux v6.12 release. I observed this
issue while conducting stability and fuzzing tests on the Android 16
platform and identified that the root cause lies in the upstream
codebase.


Bug Location: may_delete+0x72c/0x730 fs/namei.c:3066

Bug Report: https://hastebin.com/share/amuhawituy.scss

Entire Log: https://hastebin.com/share/oponarusih.perl


Thank you very much for your time and attention. I sincerely apologize
that I am currently unable to provide a reproducer for this issue.
However, I am actively working on reproducing the problem, and I will
make sure to share any findings or reproducing steps with you as soon
as they are available.

I greatly appreciate your efforts in maintaining the Linux kernel and
your attention to this matter.

Best regards,
Luka

[BUG] task hung in fs_bdev_sync in linux v6.12

[Luka]

Dear Kernel Maintainers,

I am writing to report a potential vulnerability identified in the
upstream Linux Kernel version v6.12, corresponding to the following
commit in the mainline repository:

Git Commit:  adc218676eef25575469234709c2d87185ca223a (tag: v6.12)

This issue was discovered during the testing of the Android 16 AOSP
kernel, which is based on Linux kernel version 6.12, specifically from
the AOSP kernel branch:

AOSP kernel branch: android16-6.12
Manifest path: kernel/common.git
Source URL:  https://android.googlesource.com/kernel/common/+/refs/heads/android16-6.12

Although this kernel branch is used in Android 16 development, its
base is aligned with the upstream Linux v6.12 release. I observed this
issue while conducting stability and fuzzing tests on the Android 16
platform and identified that the root cause lies in the upstream
codebase.


Bug Location: fs_bdev_sync+0x2c/0x68 fs/super.c:1434

Bug Report: https://hastebin.com/share/pihohaniwi.bash

Entire Log: https://hastebin.com/share/orufevoquj.perl


Thank you very much for your time and attention. I sincerely apologize
that I am currently unable to provide a reproducer for this issue.
However, I am actively working on reproducing the problem, and I will
make sure to share any findings or reproducing steps with you as soon
as they are available.

I greatly appreciate your efforts in maintaining the Linux kernel and
your attention to this matter.

Best regards,
Luka

Re: [Bug] possible deadlock in vfs_rmdir in Linux kernel v6.12

[Christian Brauner]

Konstantin, this looks actively malicious.
Can we do something about this list-wise?

On Wed, Jun 04, 2025 at 12:38:36PM +0800, Luka wrote:
> Dear Kernel Maintainers,
> 
> I am writing to report a potential vulnerability identified in the
> upstream Linux Kernel version v6.12, corresponding to the following
> commit in the mainline repository:
> 
> Git Commit:  adc218676eef25575469234709c2d87185ca223a (tag: v6.12)
> 
> This issue was discovered during the testing of the Android 16 AOSP
> kernel, which is based on Linux kernel version 6.12, specifically from
> the AOSP kernel branch:
> 
> AOSP kernel branch: android16-6.12
> Manifest path: kernel/common.git
> Source URL:  https://android.googlesource.com/kernel/common/+/refs/heads/android16-6.12
> 
> Although this kernel branch is used in Android 16 development, its
> base is aligned with the upstream Linux v6.12 release. I observed this
> issue while conducting stability and fuzzing tests on the Android 16
> platform and identified that the root cause lies in the upstream
> codebase.
> 
> 
> Bug Location: vfs_rmdir+0x118/0x488 fs/namei.c:4329
> 
> Bug Report: https://hastebin.com/share/vobatolola.bash
> 
> Entire Log: https://hastebin.com/share/efajodumuh.perl
> 
> 
> Thank you very much for your time and attention. I sincerely apologize
> that I am currently unable to provide a reproducer for this issue.
> However, I am actively working on reproducing the problem, and I will
> make sure to share any findings or reproducing steps with you as soon
> as they are available.
> 
> I greatly appreciate your efforts in maintaining the Linux kernel and
> your attention to this matter.
> 
> Best regards,
> Luka

On Wed, Jun 04, 2025 at 12:21:40PM +0800, Luka wrote:
> Dear Kernel Maintainers,
> 
> I am writing to report a potential vulnerability identified in the
> upstream Linux Kernel version v6.12, corresponding to the following
> commit in the mainline repository:
> 
> Git Commit:  adc218676eef25575469234709c2d87185ca223a (tag: v6.12)
> 
> This issue was discovered during the testing of the Android 16 AOSP
> kernel, which is based on Linux kernel version 6.12, specifically from
> the AOSP kernel branch:
> 
> AOSP kernel branch: android16-6.12
> Manifest path: kernel/common.git
> Source URL:  https://android.googlesource.com/kernel/common/+/refs/heads/android16-6.12
> 
> Although this kernel branch is used in Android 16 development, its
> base is aligned with the upstream Linux v6.12 release. I observed this
> issue while conducting stability and fuzzing tests on the Android 16
> platform and identified that the root cause lies in the upstream
> codebase.
> 
> 
> Bug Location: may_delete+0x72c/0x730 fs/namei.c:3066
> 
> Bug Report: https://hastebin.com/share/amuhawituy.scss
> 
> Entire Log: https://hastebin.com/share/oponarusih.perl
> 
> 
> Thank you very much for your time and attention. I sincerely apologize
> that I am currently unable to provide a reproducer for this issue.
> However, I am actively working on reproducing the problem, and I will
> make sure to share any findings or reproducing steps with you as soon
> as they are available.
> 
> I greatly appreciate your efforts in maintaining the Linux kernel and
> your attention to this matter.
> 
> Best regards,
> Luka

On Wed, Jun 04, 2025 at 12:12:26PM +0800, Luka wrote:
> Dear Kernel Maintainers,
> 
> I am writing to report a potential vulnerability identified in the
> upstream Linux Kernel version v6.12, corresponding to the following
> commit in the mainline repository:
> 
> Git Commit:  adc218676eef25575469234709c2d87185ca223a (tag: v6.12)
> 
> This issue was discovered during the testing of the Android 16 AOSP
> kernel, which is based on Linux kernel version 6.12, specifically from
> the AOSP kernel branch:
> 
> AOSP kernel branch: android16-6.12
> Manifest path: kernel/common.git
> Source URL:  https://android.googlesource.com/kernel/common/+/refs/heads/android16-6.12
> 
> Although this kernel branch is used in Android 16 development, its
> base is aligned with the upstream Linux v6.12 release. I observed this
> issue while conducting stability and fuzzing tests on the Android 16
> platform and identified that the root cause lies in the upstream
> codebase.
> 
> 
> Bug Location: fs_bdev_sync+0x2c/0x68 fs/super.c:1434
> 
> Bug Report: https://hastebin.com/share/pihohaniwi.bash
> 
> Entire Log: https://hastebin.com/share/orufevoquj.perl
> 
> 
> Thank you very much for your time and attention. I sincerely apologize
> that I am currently unable to provide a reproducer for this issue.
> However, I am actively working on reproducing the problem, and I will
> make sure to share any findings or reproducing steps with you as soon
> as they are available.
> 
> I greatly appreciate your efforts in maintaining the Linux kernel and
> your attention to this matter.
> 
> Best regards,
> Luka

Re: [Bug] possible deadlock in vfs_rmdir in Linux kernel v6.12

[Konstantin Ryabitsev]

On Wed, Jun 04, 2025 at 09:45:23AM +0200, Christian Brauner wrote:
> Konstantin, this looks actively malicious.
> Can we do something about this list-wise?

Malicious in what sense? Is it just junk, or is it attempting to have
maintainers perform some potentially dangerous operation?

-K

Re: [Bug] possible deadlock in vfs_rmdir in Linux kernel v6.12

[Jan Kara]

On Wed 04-06-25 10:45:49, Konstantin Ryabitsev wrote:
> On Wed, Jun 04, 2025 at 09:45:23AM +0200, Christian Brauner wrote:
> > Konstantin, this looks actively malicious.
> > Can we do something about this list-wise?
> 
> Malicious in what sense? Is it just junk, or is it attempting to have
> maintainers perform some potentially dangerous operation?

Well, useless it is for certain but links like:

Bug Report: https://hastebin.com/share/pihohaniwi.bash

Entire Log: https://hastebin.com/share/orufevoquj.perl

are rather suspicious and suggest there's more in there than just a lack of
knowledge (but now that I've tried the suffixes seem to be automatically
added by some filetype detection logic in the hastebin.com site itself so
more likely this is not malicious after all). FWIW I've downloaded one of
the files through wget and looked into it and it seems to have a reasonable
content and does not seem malicious but it is difficult to be sure in the
maze of HTML and JS...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [Bug] possible deadlock in vfs_rmdir in Linux kernel v6.12

[Konstantin Ryabitsev]

On Wed, Jun 04, 2025 at 05:44:22PM +0200, Jan Kara wrote:
> > Malicious in what sense? Is it just junk, or is it attempting to have
> > maintainers perform some potentially dangerous operation?
> 
> Well, useless it is for certain but links like:
> 
> Bug Report: https://hastebin.com/share/pihohaniwi.bash
> 
> Entire Log: https://hastebin.com/share/orufevoquj.perl
> 
> are rather suspicious and suggest there's more in there than just a lack of
> knowledge (but now that I've tried the suffixes seem to be automatically
> added by some filetype detection logic in the hastebin.com site itself so
> more likely this is not malicious after all). FWIW I've downloaded one of
> the files through wget and looked into it and it seems to have a reasonable
> content and does not seem malicious but it is difficult to be sure in the
> maze of HTML and JS...

Yes, hence my question. I think it's just a bad medium. It's actually the kind
of thing that bugzilla is okay to use for -- create a bug with attachments and
report it to the list, so maybe the original author can use that instead of
pastebin sites?

-K

Re: [Bug] possible deadlock in vfs_rmdir in Linux kernel v6.12

[Matthew Wilcox]

On Wed, Jun 04, 2025 at 04:11:21PM -0400, Konstantin Ryabitsev wrote:
> Yes, hence my question. I think it's just a bad medium. It's actually the kind
> of thing that bugzilla is okay to use for -- create a bug with attachments and
> report it to the list, so maybe the original author can use that instead of
> pastebin sites?

The "author" looks to be a bot, frankly.  At best yet-another-incompetent
user of "my modified version of syzkaller".  There's no signal here,
would recommend just banning.

Re: [Bug] possible deadlock in vfs_rmdir in Linux kernel v6.12

[Al Viro]

On Wed, Jun 04, 2025 at 09:39:20PM +0100, Matthew Wilcox wrote:
> On Wed, Jun 04, 2025 at 04:11:21PM -0400, Konstantin Ryabitsev wrote:
> > Yes, hence my question. I think it's just a bad medium. It's actually the kind
> > of thing that bugzilla is okay to use for -- create a bug with attachments and
> > report it to the list, so maybe the original author can use that instead of
> > pastebin sites?
> 
> The "author" looks to be a bot, frankly.  At best yet-another-incompetent
> user of "my modified version of syzkaller".  There's no signal here,
> would recommend just banning.

FWIW, I suspect that we ought to document that *anything* (bug reports,
patches, etc.) sent should be reachable without the need to run javascript
or any similar crap.  Not sure what would be the best place for that,
though...

Seriously, this is pretty much on the same level as "don't send me
a binary as reproducer - I'm not going to run it".  Folks on these
lists are fairly tempting as targets; betting on the sandbox quality
in chromium/firepox/whatnot...  sorry, no.

*IF* hastebin really produces crap that can't be accessed without
interpreter of some sort, just bounce any mail that contains such links
with the obvious explanation.