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

[Vladimir Riabchun]

On 10/28/26 12:58, Pavel Tikhomirov wrote:
>> 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.

The simplest solution I see is to delay init_cred/ve_nsproxy destruction
until ve_destroy. So stale users will still have access to user_ns/etc.

> 
>>
>> [ 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;
> 	...
> }

Yep, but this is a different problem.
I think it should be handled in a separate task - require
override_cred number matching override_ve when doing ve_capable.

Here I think it is not distinguishable from underlying fs issues,
so we probably won't crash the system.

> 

-- 
Best regards, Riabchun Vladimir
Linux Kernel Developer, Virtuozzo