<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/orangefs, branch v6.6.132</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-11-24T09:29:45+00:00</updated>
<entry>
<title>orangefs: fix xattr related buffer overflow...</title>
<updated>2025-11-24T09:29:45+00:00</updated>
<author>
<name>Mike Marshall</name>
<email>hubcap@omnibond.com</email>
</author>
<published>2025-09-15T21:40:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e09a096104fc65859422817fb2211f35855983fe'/>
<id>urn:sha1:e09a096104fc65859422817fb2211f35855983fe</id>
<content type='text'>
[ Upstream commit 025e880759c279ec64d0f754fe65bf45961da864 ]

Willy Tarreau &lt;w@1wt.eu&gt; forwarded me a message from
Disclosure &lt;disclosure@aisle.com&gt; with the following
warning:

&gt; The helper `xattr_key()` uses the pointer variable in the loop condition
&gt; rather than dereferencing it. As `key` is incremented, it remains non-NULL
&gt; (until it runs into unmapped memory), so the loop does not terminate on
&gt; valid C strings and will walk memory indefinitely, consuming CPU or hanging
&gt; the thread.

I easily reproduced this with setfattr and getfattr, causing a kernel
oops, hung user processes and corrupted orangefs files. Disclosure
sent along a diff (not a patch) with a suggested fix, which I based
this patch on.

After xattr_key started working right, xfstest generic/069 exposed an
xattr related memory leak that lead to OOM. xattr_key returns
a hashed key.  When adding xattrs to the orangefs xattr cache, orangefs
used hash_add, a kernel hashing macro. hash_add also hashes the key using
hash_log which resulted in additions to the xattr cache going to the wrong
hash bucket. generic/069 tortures a single file and orangefs does a
getattr for the xattr "security.capability" every time. Orangefs
negative caches on xattrs which includes a kmalloc. Since adds to the
xattr cache were going to the wrong bucket, every getattr for
"security.capability" resulted in another kmalloc, none of which were
ever freed.

I changed the two uses of hash_add to hlist_add_head instead
and the memory leak ceased and generic/069 quit throwing furniture.

Signed-off-by: Mike Marshall &lt;hubcap@omnibond.com&gt;
Reported-by: Stanislav Fort of Aisle Research &lt;stanislav.fort@aisle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs/orangefs: use snprintf() instead of sprintf()</title>
<updated>2025-08-28T14:28:25+00:00</updated>
<author>
<name>Amir Mohammad Jahangirzad</name>
<email>a.jahangirzad@gmail.com</email>
</author>
<published>2025-06-08T16:35:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=478bd3bc4e7f14aed79cc6220d81f87c205d462c'/>
<id>urn:sha1:478bd3bc4e7f14aed79cc6220d81f87c205d462c</id>
<content type='text'>
[ Upstream commit cdfa1304657d6f23be8fd2bb0516380a3c89034e ]

sprintf() is discouraged for use with bounded destination buffers
as it does not prevent buffer overflows when the formatted output
exceeds the destination buffer size. snprintf() is a safer
alternative as it limits the number of bytes written and ensures
NUL-termination.

Replace sprintf() with snprintf() for copying the debug string
into a temporary buffer, using ORANGEFS_MAX_DEBUG_STRING_LEN as
the maximum size to ensure safe formatting and prevent memory
corruption in edge cases.

EDIT: After this patch sat on linux-next for a few days, Dan
Carpenter saw it and suggested that I use scnprintf instead of
snprintf. I made the change and retested.

Signed-off-by: Amir Mohammad Jahangirzad &lt;a.jahangirzad@gmail.com&gt;
Signed-off-by: Mike Marshall &lt;hubcap@omnibond.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs/orangefs: Allow 2 more characters in do_c_string()</title>
<updated>2025-08-15T10:08:55+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2025-07-19T14:19:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=25d15b0d2b422f312851c3323c39eb66b3e0536a'/>
<id>urn:sha1:25d15b0d2b422f312851c3323c39eb66b3e0536a</id>
<content type='text'>
[ Upstream commit 2138e89cb066b40386b1d9ddd61253347d356474 ]

The do_k_string() and do_c_string() functions do essentially the same
thing which is they add a string and a comma onto the end of an existing
string.  At the end, the caller will overwrite the last comma with a
newline.  Later, in orangefs_kernel_debug_init(), we add a newline to
the string.

The change to do_k_string() is just cosmetic.  I moved the "- 1" to
the other side of the comparison and made it "+ 1".  This has no
effect on runtime, I just wanted the functions to match each other
and the rest of the file.

However in do_c_string(), I removed the "- 2" which allows us to print
two extra characters.  I noticed this issue while reviewing the code
and I doubt affects anything in real life.  My guess is that this was
double counting the comma and the newline.  The "+ 1" accounts for
the newline, and the caller will delete the final comma which ensures
there is enough space for the newline.

Removing the "- 2" lets us print 2 more characters, but mainly it makes
the code more consistent and understandable for reviewers.

Fixes: 44f4641073f1 ("orangefs: clean up debugfs globals")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Mike Marshall &lt;hubcap@omnibond.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>orangefs: Do not truncate file size</title>
<updated>2025-06-04T12:42:02+00:00</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
<email>willy@infradead.org</email>
</author>
<published>2025-03-05T20:47:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=121f0335d91e46369bf55b5da4167d82b099a166'/>
<id>urn:sha1:121f0335d91e46369bf55b5da4167d82b099a166</id>
<content type='text'>
[ Upstream commit 062e8093592fb866b8e016641a8b27feb6ac509d ]

'len' is used to store the result of i_size_read(), so making 'len'
a size_t results in truncation to 4GiB on 32-bit systems.

Signed-off-by: "Matthew Wilcox (Oracle)" &lt;willy@infradead.org&gt;
Link: https://lore.kernel.org/r/20250305204734.1475264-2-willy@infradead.org
Tested-by: Mike Marshall &lt;hubcap@omnibond.com&gt;
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>orangefs: fix a oob in orangefs_debug_write</title>
<updated>2025-02-21T12:57:12+00:00</updated>
<author>
<name>Mike Marshall</name>
<email>hubcap@omnibond.com</email>
</author>
<published>2025-01-08T19:21:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b84a231910cef2e0a16d29294afabfb69112087'/>
<id>urn:sha1:2b84a231910cef2e0a16d29294afabfb69112087</id>
<content type='text'>
[ Upstream commit f7c848431632598ff9bce57a659db6af60d75b39 ]

I got a syzbot report: slab-out-of-bounds Read in
orangefs_debug_write... several people suggested fixes,
I tested Al Viro's suggestion and made this patch.

Signed-off-by: Mike Marshall &lt;hubcap@omnibond.com&gt;
Reported-by: syzbot+fc519d7875f2d9186c1f@syzkaller.appspotmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>orangefs: fix out-of-bounds fsid access</title>
<updated>2024-07-11T10:49:08+00:00</updated>
<author>
<name>Mike Marshall</name>
<email>hubcap@omnibond.com</email>
</author>
<published>2024-05-01T20:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6a3cacf6d3cf0278aa90392aef2fc3fe2717a047'/>
<id>urn:sha1:6a3cacf6d3cf0278aa90392aef2fc3fe2717a047</id>
<content type='text'>
[ Upstream commit 53e4efa470d5fc6a96662d2d3322cfc925818517 ]

Arnd Bergmann sent a patch to fsdevel, he says:

"orangefs_statfs() copies two consecutive fields of the superblock into
the statfs structure, which triggers a warning from the string fortification
helpers"

Jan Kara suggested an alternate way to do the patch to make it more readable.

I ran both ideas through xfstests and both seem fine. This patch
is based on Jan Kara's suggestion.

Signed-off-by: Mike Marshall &lt;hubcap@omnibond.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Julia Lawall reported this null pointer dereference, this should fix it.</title>
<updated>2024-04-13T11:07:35+00:00</updated>
<author>
<name>Mike Marshall</name>
<email>hubcap@omnibond.com</email>
</author>
<published>2024-02-14T20:57:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=214a6c4a28c11d67044e6cf3a0ab415050d9f03a'/>
<id>urn:sha1:214a6c4a28c11d67044e6cf3a0ab415050d9f03a</id>
<content type='text'>
[ Upstream commit 9bf93dcfc453fae192fe5d7874b89699e8f800ac ]

Signed-off-by: Mike Marshall &lt;hubcap@omnibond.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs: drop the timespec64 argument from update_time</title>
<updated>2023-08-11T07:04:57+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2023-08-07T19:38:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=913e99287b98fd051ac1976140a2764a8ef9dfbf'/>
<id>urn:sha1:913e99287b98fd051ac1976140a2764a8ef9dfbf</id>
<content type='text'>
Now that all of the update_time operations are prepared for it, we can
drop the timespec64 argument from the update_time operation. Do that and
remove it from some associated functions like inode_update_time and
inode_needs_update_time.

Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Message-Id: &lt;20230807-mgctime-v7-8-d1dec143a704@kernel.org&gt;
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs: drop the timespec64 arg from generic_update_time</title>
<updated>2023-08-09T06:56:37+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2023-08-07T19:38:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=541d4c798a598854fcce7326d947cbcbd35701d6'/>
<id>urn:sha1:541d4c798a598854fcce7326d947cbcbd35701d6</id>
<content type='text'>
In future patches we're going to change how the ctime is updated
to keep track of when it has been queried. The way that the update_time
operation works (and a lot of its callers) make this difficult, since
they grab a timestamp early and then pass it down to eventually be
copied into the inode.

All of the existing update_time callers pass in the result of
current_time() in some fashion. Drop the "time" parameter from
generic_update_time, and rework it to fetch its own timestamp.

This change means that an update_time could fetch a different timestamp
than was seen in inode_needs_update_time. update_time is only ever
called with one of two flag combinations: Either S_ATIME is set, or
S_MTIME|S_CTIME|S_VERSION are set.

With this change we now treat the flags argument as an indicator that
some value needed to be updated when last checked, rather than an
indication to update specific timestamps.

Rework the logic for updating the timestamps and put it in a new
inode_update_timestamps helper that other update_time routines can use.
S_ATIME is as treated as we always have, but if any of the other three
are set, then we attempt to update all three.

Also, some callers of generic_update_time need to know what timestamps
were actually updated. Change it to return an S_* flag mask to indicate
that and rework the callers to expect it.

Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Message-Id: &lt;20230807-mgctime-v7-3-d1dec143a704@kernel.org&gt;
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs: pass the request_mask to generic_fillattr</title>
<updated>2023-08-09T06:56:36+00:00</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@kernel.org</email>
</author>
<published>2023-08-07T19:38:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0d72b92883c651a11059d93335f33d65c6eb653b'/>
<id>urn:sha1:0d72b92883c651a11059d93335f33d65c6eb653b</id>
<content type='text'>
generic_fillattr just fills in the entire stat struct indiscriminately
today, copying data from the inode. There is at least one attribute
(STATX_CHANGE_COOKIE) that can have side effects when it is reported,
and we're looking at adding more with the addition of multigrain
timestamps.

Add a request_mask argument to generic_fillattr and have most callers
just pass in the value that is passed to getattr. Have other callers
(e.g. ksmbd) just pass in STATX_BASIC_STATS. Also move the setting of
STATX_CHANGE_COOKIE into generic_fillattr.

Acked-by: Joseph Qi &lt;joseph.qi@linux.alibaba.com&gt;
Reviewed-by: Xiubo Li &lt;xiubli@redhat.com&gt;
Reviewed-by: "Paulo Alcantara (SUSE)" &lt;pc@manguebit.com&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Message-Id: &lt;20230807-mgctime-v7-2-d1dec143a704@kernel.org&gt;
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
</feed>
