Patch "bpf: Fix verification of indirect var-off stack access" has been added to the 5.15-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: Fix verification of indirect var-off stack access

to the 5.15-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-fix-verification-of-indirect-var-off-stack-acces.patch
and it can be found in the queue-5.15 subdirectory.

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



commit 72aa083b999bea9017d176a8903aa5afef994dae
Author: Andrei Matei <andreimatei1@xxxxxxxxx>
Date:   Wed Dec 6 23:11:48 2023 -0500

    bpf: Fix verification of indirect var-off stack access
    
    [ Upstream commit a833a17aeac73b33f79433d7cee68d5cafd71e4f ]
    
    This patch fixes a bug around the verification of possibly-zero-sized
    stack accesses. When the access was done through a var-offset stack
    pointer, check_stack_access_within_bounds was incorrectly computing the
    maximum-offset of a zero-sized read to be the same as the register's min
    offset. Instead, we have to take in account the register's maximum
    possible value. The patch also simplifies how the max offset is checked;
    the check is now simpler than for min offset.
    
    The bug was allowing accesses to erroneously pass the
    check_stack_access_within_bounds() checks, only to later crash in
    check_stack_range_initialized() when all the possibly-affected stack
    slots are iterated (this time with a correct max offset).
    check_stack_range_initialized() is relying on
    check_stack_access_within_bounds() for its accesses to the
    stack-tracking vector to be within bounds; in the case of zero-sized
    accesses, we were essentially only verifying that the lowest possible
    slot was within bounds. We would crash when the max-offset of the stack
    pointer was >= 0 (which shouldn't pass verification, and hopefully is
    not something anyone's code attempts to do in practice).
    
    Thanks Hao for reporting!
    
    Fixes: 01f810ace9ed3 ("bpf: Allow variable-offset stack access")
    Reported-by: Hao Sun <sunhao.th@xxxxxxxxx>
    Signed-off-by: Andrei Matei <andreimatei1@xxxxxxxxx>
    Signed-off-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
    Acked-by: Eduard Zingerman <eddyz87@xxxxxxxxx>
    Acked-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
    Link: https://lore.kernel.org/bpf/20231207041150.229139-2-andreimatei1@xxxxxxxxx
    
    Closes: https://lore.kernel.org/bpf/CACkBjsZGEUaRCHsmaX=h-efVogsRfK1FPxmkgb0Os_frnHiNdw@xxxxxxxxxxxxxx/
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index cc284371eea0..c2ecf349523d 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -4305,10 +4305,7 @@ static int check_stack_access_within_bounds(
 
 	if (tnum_is_const(reg->var_off)) {
 		min_off = reg->var_off.value + off;
-		if (access_size > 0)
-			max_off = min_off + access_size - 1;
-		else
-			max_off = min_off;
+		max_off = min_off + access_size;
 	} else {
 		if (reg->smax_value >= BPF_MAX_VAR_OFF ||
 		    reg->smin_value <= -BPF_MAX_VAR_OFF) {
@@ -4317,15 +4314,12 @@ static int check_stack_access_within_bounds(
 			return -EACCES;
 		}
 		min_off = reg->smin_value + off;
-		if (access_size > 0)
-			max_off = reg->smax_value + off + access_size - 1;
-		else
-			max_off = min_off;
+		max_off = reg->smax_value + off + access_size;
 	}
 
 	err = check_stack_slot_within_bounds(min_off, state, type);
-	if (!err)
-		err = check_stack_slot_within_bounds(max_off, state, type);
+	if (!err && max_off > 0)
+		err = -EINVAL; /* out of stack access into non-negative offsets */
 
 	if (err) {
 		if (tnum_is_const(reg->var_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