Hi,
I confirm Leonardo's findings about 6.1.70 introducing this regression,
this issue manifested in Home Assistant OS [1] which was recently bumped
to that version. I bisected the issue between 6.1.69 and 6.1.70 which
pointed me to this bad commit:
----
commit bef4315f19ba6f434054f58b958c0cf058c7a43f (refs/bisect/bad)
Author: Paulo Alcantara <pc@xxxxxxxxxxxxx>
Date: Wed Dec 13 12:25:57 2023 -0300
smb: client: fix OOB in SMB2_query_info_init()
commit 33eae65c6f49770fec7a662935d4eb4a6406d24b upstream.
A small CIFS buffer (448 bytes) isn't big enough to hold
SMB2_QUERY_INFO request along with user's input data from
CIFS_QUERY_INFO ioctl. That is, if the user passed an input buffer >
344 bytes, the client will memcpy() off the end of @req->Buffer in
SMB2_query_info_init() thus causing the following KASAN splat:
(snip...)
----
Reverting this change on 6.1.y makes the error go away.
Adding linux-cifs and Paolo to CC.
Cheers,
Jan
[1] https://github.com/home-assistant/operating-system/issues/3041
On 08. 01. 24 11:44, Leonardo Brondani Schenkel wrote:
I'm new here, first time reporting a regression, apologies in advance if
I'm doing something wrong of if this was already reported (I found some
CIFS issues but not exactly this one).
I'm using x86-64 Arch Linux and LTS kernel (6.1.71 as I write this) and
I noticed a regression that I could reproduce in other boxes with other
architectures as well (aarch64 with 6.1.70).
# mount.cifs //server/share /mnt
# mount
//server/share on /mnt type cifs (rw,relatime,vers=3.1.1...)
# cd /mnt
# df .
df: .: Resource temporarily unavailable
# ls -al
ls: .: Resource temporarily unavailable
ls: file1: Resource temporarily unavailable
ls: file2: Resource temporarily unavailable
[...then ls shows the listing...]
If I use strace with df, the problem is:
statfs(".", 0x.....) = -1 EAGAIN (Resource temporarily unavailable)
And with ls:
listxattr(".", 0x..., 152): -1 EAGAIN (Resource temporarily unavailable)
listxattr("file1", ..., 152): -1 EAGAIN (same as above)
...
Initially I thought the problem was with the Samba server and/or the
client mount flags, but I've spent a day trying a *lot* of different
combinations and nothing worked. This happens with any share that I try,
and I've tried mounting shares from multiple Linux boxes running
different Samba and kernel versions.
Then I tried changing kernel versions at my client box. I booted latest
6.6.9 and the problem simply disappeared. My Debian server with 6.5.11
also doesn't have it. I then started a VM and tried a "bisection" of
6.1.x versions, leading to kernel 6.1.70 when this started to happen.
6.1.69 and older look fine.
I hope that this is enough information to reproduce this issue. I will
be glad to provide more info if necessary.
// Leonardo.