FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F13.3 2024-08-07T13:37:00Z 2024-08-07T13:37:00Z Rick Macklem rmacklem@FreeBSD.org 2024-07-21T22:56:16Z urn:sha1:3d5cb2b9a97c54ae013568a358f24e8eca51c75f The NFS RFCs are pretty loose with respect to what characters can be in a filename returned by a Readdir. However, FreeBSD, as a POSIX system will not handle imbedded '/' or nul characters in file names. Also, for NFSv4, the file names "." and ".." are handcrafted on the client and should not be returned by a NFSv4 server. This patch scans for the above in filenames returned by Readdir and ignores any entry returned by Readdir which has them in it. Because an imbedded nul would be a string terminator, it was not possible to code this check efficiently using string(3) functions. Approved by: so Security: FreeBSD-SA-24:07.nfsclient Security: CVE-2024-6759 Reported by: Apple Security Engineering and Architecture (SEAR) (cherry picked from commit 026cdaa3b3a92574d9ac3155216e5cc0b0bd4c51) (cherry picked from commit 0172b5145ad9435569978ed4d268b9f65ac59526) 2024-02-23T12:42:34Z Stefan Eßer se@FreeBSD.org 2024-02-20T12:02:24Z urn:sha1:6831288c8c4091c533c590d2d3cbb07459f2d28b FAT file systems do not use inodes, instead all file meta-information is stored in directory entries. FAT12 and FAT16 use a fixed size area for root directories, with typically 512 entries of 32 bytes each (for a total of 16 KB) on hard disk formats. The file system data is stored in clusters of typically 512 to 4096 bytes, depending on the size of the file system. The current code uses the offset of a DOS 8.3 style directory entry as a pseudo-inode, which leads to inode values of 0 to 16368 for typical root directories with 512 entries. Sub-directories use 2 cluster length plus the byte offset of the directory entry in the data area for the pseudo-inode, which may be as low as 1024 in case of 512 byte clusters. A sub-directory in cluster 2 and with 512 byte clusters will therefore lead to a re-use of inode 1024 when there are at least 32 DOS 8.3 style filenames in the root directory (or 11 14-character Windows long file names, each of which takes up 3 directory entries). FAT32 file systems are not affected by this issue and FAT12/FAT16 file systems with larger cluster sizes are unlikely to have as many directory entries in the root directory as are required to cause the collision. This commit leads to inode numbers that are guaranteed to not collide for all valid FAT12 and FAT16 file system parameters. It does also provide a small speed-up due to more efficient use of the vnode cache. PR: 277239 Reviewed by: mckusick Approved by: re (cperciva) (cherry picked from commit 445d3d227e68f85157d0301d1706aa488e8423da) (cherry picked from commit a495e7f5c5c2088bf32cd7349e2ca344ee089552) 2024-02-21T13:31:26Z Stefan Eßer se@FreeBSD.org 2024-02-17T21:04:49Z urn:sha1:00c958f12c3da158fe79c6976337eee870714fa3 PR: 268005 Reviewed by: mckusick Approved by: re (cperciva) (cherry picked from commit 8b67c670a49b4efe7e1557121b5bbae682ea3bc7) (cherry picked from commit 5f4753501e9cc59e0d15f849c9459478ea5c8dc7) 2024-02-12T20:17:13Z Alan Somers asomers@FreeBSD.org 2024-01-25T15:19:37Z urn:sha1:f2c72486da30eda54f0db1a9b7ca822afc835ecf If a file system's on-disk format does not support st_birthtime, it isn't clear what value it should return in stat(2). Neither our man page nor the OpenGroup specifies. But our convention for UFS and msdosfs is to return { .tv_sec = -1, .tv_nsec = 0 }. fusefs is different. It returns { .tv_sec = -1, .tv_nsec = -1 }. It's done that ever since the initial import in SVN r241519. Most software apparently handles this just fine. It must, because we've had no complaints. But the Rust standard library will panic when reading such a timestamp during std::fs::metadata, even if the caller doesn't care about that particular value. That's a separate bug, and should be fixed. Change our invalid value to match msdosfs and ufs, pacifying the Rust standard library. PR: 276602 Sponsored by: Axcient Reviewed by: emaste Approved by: re (cperciva) Differential Revision: https://reviews.freebsd.org/D43590 (cherry picked from commit 65e25e4a614a99243e7419279b294e399991dfff) 2024-01-25T06:51:59Z Gordon Bergling gbe@FreeBSD.org 2024-01-20T16:24:22Z urn:sha1:664eac6c91515e2472c3d7a7cba6588b17fb8ba0 - s/userpace/userspace/ (cherry picked from commit 6f0da017c973f40c1bc70552c922c500a0a8c858) 2024-01-24T13:04:38Z Konstantin Belousov kib@FreeBSD.org 2024-01-19T23:50:48Z urn:sha1:bbcc33086adc5e2baba3c97f1e53fedcaa504edb PR: 276408 (cherry picked from commit 4b3ffc5918b9968ea6ddee6f6cdf3538072e5ef4) 2024-01-24T13:04:38Z Konstantin Belousov kib@FreeBSD.org 2024-01-18T15:35:56Z urn:sha1:e45f10165847baf419dbec40d0f10c0b2864442f (cherry picked from commit 13ccb04589e2c5c840e19b407a59e44cb70ac28e) 2024-01-24T13:04:38Z Konstantin Belousov kib@FreeBSD.org 2024-01-17T23:05:55Z urn:sha1:2ce0f6fb8d830913b978bd5ff8a1fbdab94a3ce5 (cherry picked from commit 661db9b390b4a40418d838876b58d2186d72aabf) 2024-01-24T13:04:38Z Konstantin Belousov kib@FreeBSD.org 2024-01-17T22:55:05Z urn:sha1:14ef49bbadeccf6f765025af33a07886fe3dae6f PR: 276408 (cherry picked from commit be0df84849ff3e8fb5ec65176ffde88dbefdc434) 2024-01-23T06:45:52Z Gordon Bergling gbe@FreeBSD.org 2024-01-20T16:25:45Z urn:sha1:a17275e29f89d2ceb197787095eb93042631a55b - s/interpeted/interpreted/ (cherry picked from commit 7cf293536ebacc92150be12e0be928500e670610)