Re: [RFC PATCH bpf-next 0/6] bpf: Handle reuse in bpf memory alloc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 2/16/2023 3:47 PM, Martin KaFai Lau wrote:
> On 2/15/23 6:11 PM, Hou Tao wrote:
>>>>> For local storage, when its owner (sk/task/inode/cgrp) is going away, the
>>>>> memory can be reused immediately. No rcu gp is needed.
>>>> Now it seems it will wait for RCU GP and i think it is still necessary,
>>>> because
>>>> when the process exits, other processes may still access the local storage
>>>> through pidfd or task_struct of the exited process.
>>> When its owner (sk/task/cgrp...) is going away, its owner has reached refcnt 0
>>> and will be kfree immediately next. eg. bpf_sk_storage_free is called just
>>> before the sk is about to be kfree. No bpf prog should have a hold on this sk.
>>> The same should go for the task.
>> A bpf syscall may have already found the task local storage through a pidfd,
>> then the target task exits and the local storage is free immediately, then bpf
>> syscall starts to copy the local storage and there will be a UAF, right ? Did I
>> missing something here ?
> bpf syscall like bpf_pid_task_storage_lookup_elem and you meant
> __put_task_struct() will be called while the syscall's bpf_map_copy_value() is
> still under rcu_read_lock()?
Yes, but I known it is impossible here. I missed that task_struct is released
through call_rcu(), so the calling of __put_task_struct() must happen after the
completion of bpf_map_copy_value() in bpf syscall. Thanks for the explanation.




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux