Patch "bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID" has been added to the 6.1-stable tree

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

 



This is a note to let you know that I've just added the patch titled

    bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID

to the 6.1-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     bpf-clobber-stack-slot-when-writing-over-spilled-ptr.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 14907eb7a6e145f2b2a48bc57f8c5da961d16b26
Author: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
Date:   Fri Nov 4 00:39:52 2022 +0530

    bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID
    
    [ Upstream commit 261f4664caffdeb9dff4e83ee3c0334b1c3a552f ]
    
    When support was added for spilled PTR_TO_BTF_ID to be accessed by
    helper memory access, the stack slot was not overwritten to STACK_MISC
    (and that too is only safe when env->allow_ptr_leaks is true).
    
    This means that helpers who take ARG_PTR_TO_MEM and write to it may
    essentially overwrite the value while the verifier continues to track
    the slot for spilled register.
    
    This can cause issues when PTR_TO_BTF_ID is spilled to stack, and then
    overwritten by helper write access, which can then be passed to BPF
    helpers or kfuncs.
    
    Handle this by falling back to the case introduced in a later commit,
    which will also handle PTR_TO_BTF_ID along with other pointer types,
    i.e. cd17d38f8b28 ("bpf: Permits pointers on stack for helper calls").
    
    Finally, include a comment on why REG_LIVE_WRITTEN is not being set when
    clobber is set to true. In short, the reason is that while when clobber
    is unset, we know that we won't be writing, when it is true, we *may*
    write to any of the stack slots in that range. It may be a partial or
    complete write, to just one or many stack slots.
    
    We cannot be sure, hence to be conservative, we leave things as is and
    never set REG_LIVE_WRITTEN for any stack slot. However, clobber still
    needs to reset them to STACK_MISC assuming writes happened. However read
    marks still need to be propagated upwards from liveness point of view,
    as parent stack slot's contents may still continue to matter to child
    states.
    
    Cc: Yonghong Song <yhs@xxxxxxxx>
    Fixes: 1d68f22b3d53 ("bpf: Handle spilled PTR_TO_BTF_ID properly when checking stack_boundary")
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
    Link: https://lore.kernel.org/r/20221103191013.1236066-4-memxor@xxxxxxxxx
    Signed-off-by: Alexei Starovoitov <ast@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 264b3dc714cc..146056c79cc9 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5159,10 +5159,6 @@ static int check_stack_range_initialized(
 			goto mark;
 		}
 
-		if (is_spilled_reg(&state->stack[spi]) &&
-		    base_type(state->stack[spi].spilled_ptr.type) == PTR_TO_BTF_ID)
-			goto mark;
-
 		if (is_spilled_reg(&state->stack[spi]) &&
 		    (state->stack[spi].spilled_ptr.type == SCALAR_VALUE ||
 		     env->allow_ptr_leaks)) {
@@ -5193,6 +5189,11 @@ static int check_stack_range_initialized(
 		mark_reg_read(env, &state->stack[spi].spilled_ptr,
 			      state->stack[spi].spilled_ptr.parent,
 			      REG_LIVE_READ64);
+		/* We do not set REG_LIVE_WRITTEN for stack slot, as we can not
+		 * be sure that whether stack slot is written to or not. Hence,
+		 * we must still conservatively propagate reads upwards even if
+		 * helper may write to the entire memory range.
+		 */
 	}
 	return update_stack_depth(env, state, min_off);
 }



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux