[PATCH] fs: Document 'name' parameter in name_contains_dotdot()

Prithvi Tambewagh posted 1 patch 1 month, 1 week ago
include/linux/fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] fs: Document 'name' parameter in name_contains_dotdot()
Posted by Prithvi Tambewagh 1 month, 1 week ago
Add documentation for the 'name' parameter in name_contains_dotdot()

Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>
---
 include/linux/fs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index d7ab4f96d705..64e3c99d60f6 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3281,7 +3281,7 @@ static inline bool is_dot_dotdot(const char *name, size_t len)
 
 /**
  * name_contains_dotdot - check if a file name contains ".." path components
- *
+ * @name: file name to  check
  * Search for ".." surrounded by either '/' or start/end of string.
  */
 static inline bool name_contains_dotdot(const char *name)
-- 
2.34.1
Re: [PATCH] fs: Document 'name' parameter in name_contains_dotdot()
Posted by Al Viro 1 month, 1 week ago
On Sat, Aug 23, 2025 at 07:52:08PM +0530, Prithvi Tambewagh wrote:
> Add documentation for the 'name' parameter in name_contains_dotdot()
> 
> Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>

Out of curiosity, could you describe the process that has lead to
that patch?

The reason why I'm asking is that there had been a truly ridiculous
amount of identical patches, all dealing with exact same function.

Odds of random coincedence are very low - there's quite lot of
similar places, and AFAICS you are the 8th poster choosing the
same one.

I would expect that kind of response to a "kernel throws scary
warnings on boot for reasonably common setups", but for a comment
about a function being slightly wrong this kind of focus is
strange.

If that's some AI (s)tool responding to prompts along the lines of
"I want to fix some kernel problem, find some low-hanging fruit
and gimme a patch", we might be seeing a small-scale preview of
a future DDoS with the same underlying mechanism...
Re: [PATCH] fs: Document 'name' parameter in name_contains_dotdot()
Posted by Eric Biggers 1 month, 1 week ago
On Sun, Aug 24, 2025 at 02:06:23AM +0100, Al Viro wrote:
> On Sat, Aug 23, 2025 at 07:52:08PM +0530, Prithvi Tambewagh wrote:
> > Add documentation for the 'name' parameter in name_contains_dotdot()
> > 
> > Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>
> 
> Out of curiosity, could you describe the process that has lead to
> that patch?
> 
> The reason why I'm asking is that there had been a truly ridiculous
> amount of identical patches, all dealing with exact same function.
> 
> Odds of random coincedence are very low - there's quite lot of
> similar places, and AFAICS you are the 8th poster choosing the
> same one.
> 
> I would expect that kind of response to a "kernel throws scary
> warnings on boot for reasonably common setups", but for a comment
> about a function being slightly wrong this kind of focus is
> strange.
> 
> If that's some AI (s)tool responding to prompts along the lines of
> "I want to fix some kernel problem, find some low-hanging fruit
> and gimme a patch", we might be seeing a small-scale preview of
> a future DDoS with the same underlying mechanism...

You do know that kernel-doc warns about this, right?

    $ ./scripts/kernel-doc -v -none include/linux/fs.h
    [...]
    Warning: include/linux/fs.h:3287 function parameter 'name' not described in 'name_contains_dotdot'

It's the only warning in include/linux/fs.h.

- Eric
Re: [PATCH] fs: Document 'name' parameter in name_contains_dotdot()
Posted by Al Viro 1 month, 1 week ago
On Sat, Aug 23, 2025 at 09:52:24PM -0400, Eric Biggers wrote:
> On Sun, Aug 24, 2025 at 02:06:23AM +0100, Al Viro wrote:
> > On Sat, Aug 23, 2025 at 07:52:08PM +0530, Prithvi Tambewagh wrote:
> > > Add documentation for the 'name' parameter in name_contains_dotdot()
> > > 
> > > Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>
> > 
> > Out of curiosity, could you describe the process that has lead to
> > that patch?
> > 
> > The reason why I'm asking is that there had been a truly ridiculous
> > amount of identical patches, all dealing with exact same function.
> > 
> > Odds of random coincedence are very low - there's quite lot of
> > similar places, and AFAICS you are the 8th poster choosing the
> > same one.
> > 
> > I would expect that kind of response to a "kernel throws scary
> > warnings on boot for reasonably common setups", but for a comment
> > about a function being slightly wrong this kind of focus is
> > strange.
> > 
> > If that's some AI (s)tool responding to prompts along the lines of
> > "I want to fix some kernel problem, find some low-hanging fruit
> > and gimme a patch", we might be seeing a small-scale preview of
> > a future DDoS with the same underlying mechanism...
> 
> You do know that kernel-doc warns about this, right?
> 
>     $ ./scripts/kernel-doc -v -none include/linux/fs.h
>     [...]
>     Warning: include/linux/fs.h:3287 function parameter 'name' not described in 'name_contains_dotdot'
> 
> It's the only warning in include/linux/fs.h.

; ./scripts/kernel-doc -v -none include/linux/*.h 2>&1|grep -c Warning.*function\ parameter
 145

I rest my point.  If one of those has managed to generate 8 duplicate patches
(and the earliest one has landed in linux-next within a day) and people are
still sending that stuff...  I'd say we have a problem.

Whatever underlying mechanism is in action, it seems to have the makings of
a large DDoS.  I'm not blaming the people sending that and I would really
like to understand the mechanism behind this, er, synchronicity.