cve/published/2022/CVE-2022-49658.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2022-49658: bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals

 Description
 ===========

 In the Linux kernel, the following vulnerability has been resolved:

 bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals

 Kuee reported a corner case where the tnum becomes constant after the call
 to __reg_bound_offset(), but the register's bounds are not, that is, its
 min bounds are still not equal to the register's max bounds.

 This in turn allows to leak pointers through turning a pointer register as
 is into an unknown scalar via adjust_ptr_min_max_vals().

 Before:

   func#0 @0
   0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
   0: (b7) r0 = 1                        ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0))
   1: (b7) r3 = 0                        ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0))
   2: (87) r3 = -r3                      ; R3_w=scalar()
   3: (87) r3 = -r3                      ; R3_w=scalar()
   4: (47) r3 |= 32767                   ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881)
   5: (75) if r3 s>= 0x0 goto pc+1       ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
   6: (95) exit

   from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
   7: (d5) if r3 s<= 0x8000 goto pc+1    ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
   8: (95) exit

   from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
   9: (07) r3 += -32767                  ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0))  <--- [*]
   10: (95) exit

 What can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff;
 0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, that
 is, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off has
 not been done at that point via __update_reg_bounds(), which would have improved
 the umax to be equal to umin.

 Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync()
 helper and use it consistently everywhere. After the fix, bounds have been
 corrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the register
 is regarded as a 'proper' constant scalar of 0.

 After:

   func#0 @0
   0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
   0: (b7) r0 = 1                        ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0))
   1: (b7) r3 = 0                        ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0))
   2: (87) r3 = -r3                      ; R3_w=scalar()
   3: (87) r3 = -r3                      ; R3_w=scalar()
   4: (47) r3 |= 32767                   ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881)
   5: (75) if r3 s>= 0x0 goto pc+1       ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
   6: (95) exit

   from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
   7: (d5) if r3 s<= 0x8000 goto pc+1    ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
   8: (95) exit

   from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
   9: (07) r3 += -32767                  ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0))  <--- [*]
   10: (95) exit

 The Linux kernel CVE team has assigned CVE-2022-49658 to this issue.


 Affected and fixed versions
 ===========================

 	Issue introduced in 4.14 with commit b03c9f9fdc37dab81ea04d5dacdc5995d4c224c2 and fixed in 5.10.130 with commit e917be1f83ea14a68b3cf64d3da9968eaf991dae
 	Issue introduced in 4.14 with commit b03c9f9fdc37dab81ea04d5dacdc5995d4c224c2 and fixed in 5.15.54 with commit a7de8d436db92bab8b1f44624297c2554a6ac36b
 	Issue introduced in 4.14 with commit b03c9f9fdc37dab81ea04d5dacdc5995d4c224c2 and fixed in 5.18.11 with commit b2a28bb36664c94375926cbbb91976242847699d
 	Issue introduced in 4.14 with commit b03c9f9fdc37dab81ea04d5dacdc5995d4c224c2 and fixed in 5.19 with commit 3844d153a41adea718202c10ae91dc96b37453b5

 Please see https://www.kernel.org for a full list of currently supported
 kernel versions by the kernel community.

 Unaffected versions might change over time as fixes are backported to
 older supported kernel versions.  The official CVE entry at
 	https://cve.org/CVERecord/?id=CVE-2022-49658
 will be updated if fixes are backported, please check that for the most
 up to date information about this issue.


 Affected files
 ==============

 The file(s) affected by this issue are:
 	kernel/bpf/verifier.c


 Mitigation
 ==========

 The Linux kernel CVE team recommends that you update to the latest
 stable kernel version for this, and many other bugfixes.  Individual
 changes are never tested alone, but rather are part of a larger kernel
 release.  Cherry-picking individual commits is not recommended or
 supported by the Linux kernel community at all.  If however, updating to
 the latest release is impossible, the individual changes to resolve this
 issue can be found at these commits:
 	https://git.kernel.org/stable/c/e917be1f83ea14a68b3cf64d3da9968eaf991dae
 	https://git.kernel.org/stable/c/a7de8d436db92bab8b1f44624297c2554a6ac36b
 	https://git.kernel.org/stable/c/b2a28bb36664c94375926cbbb91976242847699d
 	https://git.kernel.org/stable/c/3844d153a41adea718202c10ae91dc96b37453b5
	From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2022-49658: bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals

	Description
	===========

	In the Linux kernel, the following vulnerability has been resolved:

	bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals

	Kuee reported a corner case where the tnum becomes constant after the call
	to __reg_bound_offset(), but the register's bounds are not, that is, its
	min bounds are still not equal to the register's max bounds.

	This in turn allows to leak pointers through turning a pointer register as
	is into an unknown scalar via adjust_ptr_min_max_vals().

	Before:

	func#0 @0
	0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
	0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0))
	1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0))
	2: (87) r3 = -r3 ; R3_w=scalar()
	3: (87) r3 = -r3 ; R3_w=scalar()
	4: (47) r3 \|= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881)
	5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
	6: (95) exit

	from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
	7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
	8: (95) exit

	from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
	9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)) <--- [*]
	10: (95) exit

	What can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff;
	0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, that
	is, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off has
	not been done at that point via __update_reg_bounds(), which would have improved
	the umax to be equal to umin.

	Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync()
	helper and use it consistently everywhere. After the fix, bounds have been
	corrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the register
	is regarded as a 'proper' constant scalar of 0.

	After:

	func#0 @0
	0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
	0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0))
	1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0))
	2: (87) r3 = -r3 ; R3_w=scalar()
	3: (87) r3 = -r3 ; R3_w=scalar()
	4: (47) r3 \|= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881)
	5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
	6: (95) exit

	from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
	7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)
	8: (95) exit

	from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))
	9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) <--- [*]
	10: (95) exit

	The Linux kernel CVE team has assigned CVE-2022-49658 to this issue.


	Affected and fixed versions
	===========================

	Issue introduced in 4.14 with commit b03c9f9fdc37dab81ea04d5dacdc5995d4c224c2 and fixed in 5.10.130 with commit e917be1f83ea14a68b3cf64d3da9968eaf991dae
	Issue introduced in 4.14 with commit b03c9f9fdc37dab81ea04d5dacdc5995d4c224c2 and fixed in 5.15.54 with commit a7de8d436db92bab8b1f44624297c2554a6ac36b
	Issue introduced in 4.14 with commit b03c9f9fdc37dab81ea04d5dacdc5995d4c224c2 and fixed in 5.18.11 with commit b2a28bb36664c94375926cbbb91976242847699d
	Issue introduced in 4.14 with commit b03c9f9fdc37dab81ea04d5dacdc5995d4c224c2 and fixed in 5.19 with commit 3844d153a41adea718202c10ae91dc96b37453b5

	Please see https://www.kernel.org for a full list of currently supported
	kernel versions by the kernel community.

	Unaffected versions might change over time as fixes are backported to
	older supported kernel versions. The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49658
	will be updated if fixes are backported, please check that for the most
	up to date information about this issue.


	Affected files
	==============

	The file(s) affected by this issue are:
	kernel/bpf/verifier.c


	Mitigation
	==========

	The Linux kernel CVE team recommends that you update to the latest
	stable kernel version for this, and many other bugfixes. Individual
	changes are never tested alone, but rather are part of a larger kernel
	release. Cherry-picking individual commits is not recommended or
	supported by the Linux kernel community at all. If however, updating to
	the latest release is impossible, the individual changes to resolve this
	issue can be found at these commits:
	https://git.kernel.org/stable/c/e917be1f83ea14a68b3cf64d3da9968eaf991dae
	https://git.kernel.org/stable/c/a7de8d436db92bab8b1f44624297c2554a6ac36b
	https://git.kernel.org/stable/c/b2a28bb36664c94375926cbbb91976242847699d
	https://git.kernel.org/stable/c/3844d153a41adea718202c10ae91dc96b37453b5