mbox series

[5.4,0/8] BPF backports for CVE-2021-29155

Message ID 20210429220839.15667-1-fllinden@amazon.com
Headers show
Series BPF backports for CVE-2021-29155 | expand

Message

Frank van der Linden April 29, 2021, 10:08 p.m. UTC
This is a backport of the BPF verifier fixes for CVE-2021-29155. Original
series was part of the pull request here: https://lore.kernel.org/bpf/20210416223700.15611-1-daniel@iogearbox.net/T/

This wasn't a complicated backport, but copying bpf@ to see if
there are any concerns.

5.4 verifier selftests are clean with this backport:
	Summary: 1566 PASSED, 0 SKIPPED, 0 FAILED

The individual commits:

960114839252 ("bpf: Use correct permission flag for mixed signed bounds arithmetic")
	* Not applicable to 5.4, as 5.4 does not have
	  2c78ee898d8f ("bpf: Implement CAP_BPF").

6f55b2f2a117 ("bpf: Move off_reg into sanitize_ptr_alu")
	* Clean cherry-pick.

24c109bb1537 ("bpf: Ensure off_reg has no mixed signed bounds for all types")
	* Conflict: allow_ptr_leaks was replaced by bypass_spec_v1 in the
	  deleted PTR_TO_MAP_VALUE switch case by
	  2c78ee898d8f ("bpf: Implement CAP_BPF"). Resolution is easy,
	  the case statement gets deleted either way.

b658bbb844e2 ("bpf: Rework ptr_limit into alu_limit and add common error path")
	* Clean cherry-pick.

a6aaece00a57 ("bpf: Improve verifier error messages for users")
	* Resolved simple contextual conflict in adjust_scalar_min_max_vals().
	  because of a var declaration that was added by this post-5.4 commit:
	  3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking").

073815b756c5 ("bpf: Refactor and streamline bounds check into helper")
	* Conflict: another allow_ptr_leaks that was replaced with
	  bypass_spec_v1 after 2c78ee898d8f.
	* Conflict: Post-5.4 commit
	  01f810ace9ed ("bpf: Allow variable-offset stack access")
	  changed the call to check_stack_access to a new function,
	  check_stack_access_for_ptr_arithmetic(), and moved/changed an
	  error message.
	* Since this commit just factors out some code from
	  adjust_ptr_min_max_vals() in to a new function, do the same
  	  with the corresponding block in 5.4 that doesn't have the
	  changes listed above from post-5.4 commits.
	
f528819334 ("bpf: Move sanitize_val_alu out of op switch")
	* Contextual conflict from post-5.4 commit
	  3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking"),
	  that added a comment on top of the switch referenced in the commit
	  message.

7fedb63a8307 ("bpf: Tighten speculative pointer arithmetic mask")
	* Contextual conflict post-5.4 commit:
	  3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking")
	  added a call to a new function just above the switch statement in
	  adjust_ptr_min_max_vals. This doesn't affect the lines that were
	  actually changed.

d7a509135175 ("bpf: Update selftests to reflect new error states")
	* The bounds.c tests have undergone several changes since 5.4, related
	  to commits that were not backported (like e.g. the ALU32 changes).
	  The error messages for those tests will remain the same on 5.4.

=====

Daniel Borkmann (8):
  bpf: Move off_reg into sanitize_ptr_alu
  bpf: Ensure off_reg has no mixed signed bounds for all types
  bpf: Rework ptr_limit into alu_limit and add common error path
  bpf: Improve verifier error messages for users
  bpf: Refactor and streamline bounds check into helper
  bpf: Move sanitize_val_alu out of op switch
  bpf: Tighten speculative pointer arithmetic mask
  bpf: Update selftests to reflect new error states

 kernel/bpf/verifier.c                         | 233 ++++++++++++------
 .../selftests/bpf/verifier/bounds_deduction.c |  21 +-
 .../bpf/verifier/bounds_mix_sign_unsign.c     |  13 -
 tools/testing/selftests/bpf/verifier/unpriv.c |   2 +-
 .../selftests/bpf/verifier/value_ptr_arith.c  |   6 +-
 5 files changed, 173 insertions(+), 102 deletions(-)

Comments

Greg KH April 30, 2021, 1:38 p.m. UTC | #1
On Thu, Apr 29, 2021 at 10:08:31PM +0000, Frank van der Linden wrote:
> This is a backport of the BPF verifier fixes for CVE-2021-29155. Original

> series was part of the pull request here: https://lore.kernel.org/bpf/20210416223700.15611-1-daniel@iogearbox.net/T/

> 

> This wasn't a complicated backport, but copying bpf@ to see if

> there are any concerns.

> 

> 5.4 verifier selftests are clean with this backport:

> 	Summary: 1566 PASSED, 0 SKIPPED, 0 FAILED

> 

> The individual commits:


Many thanks for these, now queued up.

greg k-h
Frank van der Linden April 30, 2021, 4:38 p.m. UTC | #2
Sure. I have a 4.14 one coming up too, but that one was just a little harder, and it also corrects a previous backport error that was made (correction was already acked), and picks some other commits to get selftests clean. So I'll probably send it to just bpf@ first.

Others will have to take care of 4.19 or older kernels, though, just flagging that I have done the 4.14 backport for these.

Frank

On 4/30/21, 6:39 AM, "Greg KH" <gregkh@linuxfoundation.org> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On Thu, Apr 29, 2021 at 10:08:31PM +0000, Frank van der Linden wrote:
    > This is a backport of the BPF verifier fixes for CVE-2021-29155. Original

    > series was part of the pull request here: https://lore.kernel.org/bpf/20210416223700.15611-1-daniel@iogearbox.net/T/

    >

    > This wasn't a complicated backport, but copying bpf@ to see if

    > there are any concerns.

    >

    > 5.4 verifier selftests are clean with this backport:

    >       Summary: 1566 PASSED, 0 SKIPPED, 0 FAILED

    >

    > The individual commits:


    Many thanks for these, now queued up.

    greg k-h
Greg KH May 1, 2021, 6:05 a.m. UTC | #3
On Fri, Apr 30, 2021 at 04:38:29PM +0000, van der Linden, Frank wrote:
> Sure. I have a 4.14 one coming up too, but that one was just a little harder, and it also corrects a previous backport error that was made (correction was already acked), and picks some other commits to get selftests clean. So I'll probably send it to just bpf@ first.

> 

> Others will have to take care of 4.19 or older kernels, though, just flagging that I have done the 4.14 backport for these.


I can not take fixes for 4.14 that are not also in 4.19, sorry, as we
can not have people upgrading to newer kernels and have regressions.

thanks,

greg k-h
Frank van der Linden May 1, 2021, 5:54 p.m. UTC | #4
Ok, that's fine. I can't really do 4.19 right now, someone else will have to take care of that one.

In the meantime, I'll re-send my 4.14 series with just the first two patches, that fix a 4.14-specific backport error.

Frank

On 4/30/21, 11:05 PM, "Greg KH" <gregkh@linuxfoundation.org> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On Fri, Apr 30, 2021 at 04:38:29PM +0000, van der Linden, Frank wrote:
    > Sure. I have a 4.14 one coming up too, but that one was just a little harder, and it also corrects a previous backport error that was made (correction was already acked), and picks some other commits to get selftests clean. So I'll probably send it to just bpf@ first.

    >

    > Others will have to take care of 4.19 or older kernels, though, just flagging that I have done the 4.14 backport for these.


    I can not take fixes for 4.14 that are not also in 4.19, sorry, as we
    can not have people upgrading to newer kernels and have regressions.

    thanks,

    greg k-h