[Devel] [PATCH hci-8.1 v2 4/4] ve/overlayfs: Override VE together with creds

[Pavel Tikhomirov]

> Host users might want to access overlayfs, owned by CT. In such case
> ve_capable checks will fail - they will perform VE cred checks against
> host user_ns.
> 
> Modify ovl_override_creds so that it returns both old cred and old VE.
> This will also protect us from future rebase issues - all new users of
> old_cred and ovl_override_creds will fail with compilation error.
> 
> This fixes an observed crash in overlayfs when checkpointing
> a container with a docker running inside:

What about dead creator VE? It will try to check ovl creator cred
against host userns and fail and reintroduce the crash.

AI slop:
//
ofs holds a reference on creator_ve, but after CT stop ve_drop_context()
clears ve->init_cred, and ve_capable() falls back to ve0.init_cred. With
CT creator_cred that means ns_capable(init_user_ns) -> false. So if the
superblock outlives the CT, e.g. CRIU (or any host process) has a file
open on the CT overlay while the CT dies, we again get
ovl_can_decode_fh() == true at mount time and false later, i.e.  the
same NULL dereference in ovl_get_index_name_fh() this series fixes.
//

I think dieing in the middle of CRIU c/r maybe not so rare a case.

> 
> [ 2300.870181] BUG: kernel NULL pointer dereference, address: 0000000000000005
> [ 2300.871537] #PF: supervisor read access in kernel mode
> [ 2300.872577] #PF: error_code(0x0000) - not-present page
> [ 2300.873595] PGD 800000010a18f067 P4D 800000010a18f067 PUD 10730c067 PMD 0
> [ 2300.874900] Oops: Oops: 0000 [#1] SMP PTI
> [ 2300.875742] CPU: 1 UID: 0 PID: 5419 Comm: criu ve: 0 Kdump: loaded Not tainted 6.12.0-211.39.1.16.6.vz10.x86_64 #1 16.6 PREEMPT(voluntary)
> [ 2300.878057] Hardware name: Acronis OpenStack Compute/Virtuozzo, BIOS 1.16.1-1.vz9.2 04/01/2014
> [ 2300.879684] RIP: 0010:ovl_get_index_name_fh+0x18/0x70 [overlay]
> [ 2300.880859] Code: ...
> [ 2300.884128] RSP: 0018:ffffd32582e0f7c0 EFLAGS: 00010246
> [ 2300.885153] RAX: ...
> [ 2300.895807] Call Trace:
> [ 2300.896397]
> [ 2300.903298] ? ovl_get_index_name_fh+0x18/0x70 [overlay]
> [ 2300.904435] ovl_create_index+0x82/0x260 [overlay]
> [ 2300.905406] ovl_copy_up_workdir+0x30a/0x330 [overlay]
> [ 2300.906427] ovl_do_copy_up+0x10d/0x2e0 [overlay]
> [ 2300.907387] ovl_copy_up_one+0x456/0x720 [overlay]
> [ 2300.910736] ovl_copy_up_flags+0x81/0x110 [overlay]
> [ 2300.911740] ovl_create_object+0x51/0x130 [overlay]
> [ 2300.912719] vfs_mkdir+0x194/0x250
> [ 2300.913470] do_mkdirat+0x14c/0x180
> [ 2300.914223] __x64_sys_mkdir+0x46/0x70
> [ 2300.915019] do_syscall_64+0x7d/0x160
> [ 2300.922814] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 2300.923823] RIP: 0033:0x7f5a2f8de3eb
> 
> Overlayfs was created inside CT, so ovl_fill_super stored
> in-container credentials to ofs->creator_cred.
> 
> Those creds were later used in ovl_override_creds to temporarily
> swich creds and perform checks using them.
> 
> One of these checks happened in ovl_get_origin_fh/ovl_can_decode_fh.
> On fs creation this check passed because we had container VE
> and container creds, so overlayfs thought that we support
> file handles (ovl_can_decode_fh call in ovl_make_workdir).
> 
> When we tried to do something with the overlayfs from host VE,
> ve_capable check was performed with credentials from CT
> and with host VE.
> 
> ovl_get_origin_fh returned unexpected NULL and all exploded.
> 
> Stroing ve_capable check result on creation is a possible fix,
> but it just masks the problem. We have other paths from overlay to
> ve_capable checks:
> 
> ovl_fileattr_set
>   ovl_override_creds
>   ovl_real_fileattr_set
>     vfs_fileattr_set
>       fileattr_set_prepare
>         ve_capable
> 
> And storing capability check result will make rebase dangerous - we
> would have to track new added code - not funny.

All uses of ovl_creds() are not handled, they save creator_cred to
backing file:

struct backing_file_ctx { 
        const struct cred *cred;
	...
}

-- 
Pavel Tikhomirov <ptikhomirov at virtuozzo.com>