[BUG] fs/ntfs3: an ADS rename target can overwrite a base file

[shaos]

Hello,

ntfs_rename() rejects an ADS source but accepts a target name containing the ADS delimiter.  With ads enabled, the target parser truncates f:ads to the base name f.  The existing-target branch removes f before the rename installs the source under the truncated name, silently replacing an unrelated file.

HEAD commit:    fe2ec83746e501645709761605c2464a44fd2929
git tree:       upstream Linux checkout, local branch master
source version: Linux 7.3.0-rc4-70-gfe2ec83746e50
compiler:       gcc 11.4.0, GNU ld 2.38 (from the kernel build banner)

console output:
https://gist.githubusercontent.com/shaos26/ed9ecf403e25839c2adc7cca3429b29b/raw/3b3e7b34634cf0d124b98ae8ca648213707e55af/console-output.txt
kernel config:
https://gist.githubusercontent.com/shaos26/ed9ecf403e25839c2adc7cca3429b29b/raw/5eeafdbb8044bfe53ae5eea6ab0a15ff311a3152/kernel-config.txt
reproducer:
https://gist.githubusercontent.com/shaos26/ed9ecf403e25839c2adc7cca3429b29b/raw/4bcf15d059e55bc0a19c6320263fb5e34657a5b4/poc.c

Run in a disposable VM with a fresh read-write NTFS3 image mounted so uid 65534 can write to the root directory.  The first invocation creates the files and attempts the rename; unmount and remount before the verification invocation:

    dd if=/dev/zero of=/tmp/rename.img bs=1M count=64 status=none
    mkntfs -F -q -L TEST -c 4096 -s 512 /tmp/rename.img
    mkdir -p /mnt
    mount -t ntfs3 -o loop,ads,rw,uid=65534,gid=65534,umask=000 /tmp/rename.img /mnt
    gcc -static -O2 -Wall -o ntfs3_rename_ads poc.c
    ./ntfs3_rename_ads /mnt setup-run
    umount /mnt
    mount -t ntfs3 -o loop,ads,rw,uid=65534,gid=65534,umask=000 /tmp/rename.img /mnt
    ./ntfs3_rename_ads /mnt verify-run
    umount /mnt

Three fresh vulnerable boots returned success from renameat().  After remount, a now names the original source is gone, f:ads is gone, and f resolves to the unrelated file that had previously been named a.  ads=0 preserves ordinary rename semantics.  A diagnostic fixed-kernel control rejected the ADS target and preserved all files.

Impact and prerequisites:
A local user with directory write permission on a writable NTFS3 volume can permanently lose the pre-existing target name and replace it with another file.  The operation also leaves the original MFT record and clusters leaked.  No kernel crash, memory corruption, or privilege escalation is demonstrated.

Validation: Three fresh boots reproduced silent target loss.  The ads=0 control and a diagnostic kernel that rejected the ADS target preserved the files.

Thanks,

shaos