Control: reassign -1 src:zfs-linux

On Fri, 2023-09-22 at 16:13 +0000, WHR wrote:
> Package: src:linux
> Version: 6.5.3-1
> Severity: normal
> X-Debbugs-Cc: msl0000023...@gmail.com, msl0000023...@gmail.com
> 
> 
> Taking executable file /usr/bin/ssh to demonstrate the issue:
> 
>       # which ssh
>       /usr/bin/ssh
>       # ssh                                                                   
>        
>       usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
>                  [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
>                  [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
>                  [-i identity_file] [-J [user@]host[:port]] [-L address]
>                  [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p 
> port]
>                  [-Q query_option] [-R address] [-S ctl_path] [-W host:port]
>                  [-w local_tun[:remote_tun]] destination [command]
>       # chattr +i /usr/bin/ssh                                                
>        
>       # ssh
>       Segmentation fault
> 
> 
> By trying to load the program via ld.so(1) with truss (actually strace), it 
> shows that a mmap(2) call used to load the data segument failed due to EPERM:
> 
>       # truss -s 128 -f /lib/powerpc64-linux-gnu/ld64.so.1 /usr/bin/ssh
>       execve("/lib/powerpc64-linux-gnu/ld64.so.1", 
> ["/lib/powerpc64-linux-gnu/ld64.so.1", "/usr/bin/ssh"], 0x7fffc0380530 /* 29 
> vars */) = 0
>       brk(NULL)                               = 0x1000db60000
>       openat(AT_FDCWD, "/usr/bin/ssh", O_RDONLY|O_CLOEXEC) = 3
>       read(3, 
> "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\22h\220\0\0\0\0\0\0\0@\0\0\0\0\0\22\4\330\0\0\0\1\0@\08\0\t\0@\0\35\0\34\0\0\0\6\0\0\0\4\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\1\370\0\0\0\0\0\0\1\370\0\0\0\0\0\0\0\10\0\0\0\3\0\0\0\4"...,
>  832) = 832
>       mmap(NULL, 1259760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
> 0) = 0x7fff93720000
>       mprotect(0x7fff93830000, 65536, PROT_NONE) = 0
>       mmap(0x7fff93840000, 131072, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x110000) = -1 EPERM (Operation not 
> permitted)
>       close(3)                                = 0
>       writev(2, [{iov_base="/usr/bin/ssh", iov_len=12}, {iov_base=": ", 
> iov_len=2}, {iov_base="error while loading shared libraries", iov_len=36}, 
> {iov_base=": ", iov_len=2}, {iov_base="/usr/bin/ssh", iov_len=12}, 
> {iov_base=": ", iov_len=2}, {iov_base="failed to map segment from shared 
> object", iov_len=40}, {iov_base="", iov_len=0}, {iov_base="", iov_len=0}, 
> {iov_base="\n", iov_len=1}], 10/usr/bin/ssh: error while loading shared 
> libraries: /usr/bin/ssh: failed to map segment from shared object
>       ) = 107
>       exit_group(127)                         = ?
>       +++ exited with 127 +++
> 
> 
> I can also reproduce this issue on Bullseye (with Linux 5.10.0-21-amd64);
> while Buster (Linux 4.19.0-23-amd64) is fine.
[...]
> ** Command line:
> root=ZFS=zr/ROOT/debiansid-be ro quiet 
> cgroup_enable=cpuset,cpu,cpuacct,blkio,memory,devices,freezer,net_cls,perf_event,net_prio
>  systemd.unified_cgroup_hierarchy=0 
> net.ifname-policy=keep,onboard,slot,path,kernel zfs.zfs_txg_timeout=60 
> zfs.zfs_arc_max=2166172771 init=/init
[...]

I can't reproduce this on an ext4 filesystem, so I think ZFS is the
problem.

ZFS has its own check that blocks a writable mmap of an immutable file,
without taking MAP_PRIVATE into account:
https://sources.debian.org/src/zfs-linux/2.1.12-2/module/os/linux/zfs/zfs_vnops_os.c/#L3908

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to