Bug 1215863 (CVE-2023-39191)

Patch set:

https://lore.kernel.org/all/20230121002241.2113993-1-memxor@gmail.com/

looks like this fixes commit 97e03f521050c092919591e668107b3d69c5f426, that we have in SLE15-SP5, SLE15-SP6 and stable. SLE15-SP6 and stable seems to also contain the fixing commit, while SLE15-SP5 do not.

@kernel-team, please confirm.

Reassigning to a concrete person to ensure progress [1] (feel free to pass to the next one), see also the process at [2].
 
Hi Shung-Hsi,

Could you take a look at this CVE? As Gabriele mentioned, this CVE can be solved by a patchset, which has been merged in upstream v6.3-rc1 [commit id: 84150795a49a]. It also fixes bugs introduced by 97e03f521050 that we have backported in SLE15-SP5. Since SLE15-SP6 and ALP are based on v6.4, I assume that these two repos should not be affected. Should we backport this patchset for SLE15-SP5?
 
[1] https://confluence.suse.com/display/KSS/Kernel+Security+Sentinel
[2] https://wiki.suse.net/index.php/SUSE-Labs/Kernel/Security

(In reply to Chester Lin from comment #2)
> Reassigning to a concrete person to ensure progress [1] (feel free to pass
> to the next one), see also the process at [2].

Thanks!

> Hi Shung-Hsi,
> 
> Could you take a look at this CVE? As Gabriele mentioned, this CVE can be
> solved by a patchset, which has been merged in upstream v6.3-rc1 [commit id:
> 84150795a49a]. It also fixes bugs introduced by 97e03f521050 that we have
> backported in SLE15-SP5. Since SLE15-SP6 and ALP are based on v6.4, I assume
> that these two repos should not be affected. Should we backport this
> patchset for SLE15-SP5?

Yes, we should backport to SLE15-SP5, will work on this.

I've backported the "Dynptr fixes" series to SLE15-SP5, submitted to users/syu/SLE15-SP5/for-next (head commit 9f9ad1888b35). This pulled in quite some other upstream commits along, here's the full list:
- b239da34203f bpf: Add helper macro bpf_for_each_reg_in_vstate
- e9e315b4a5de bpf: Move dynptr type check to is_dynptr_type_expected()
- "Dynptr refactorings"[1] series (dependency)
  - 6b75bd3d0367 bpf: Refactor ARG_PTR_TO_DYNPTR checks into process_dynptr_func
  - ac50fe51ce87 bpf: Propagate errors from process_* checks in check_func_arg
  - 270605317366 bpf: Rework process_dynptr_func
  - 184c9bdb8f65 bpf: Rework check_func_arg_reg_off
  - f6ee298fa140 bpf: Move PTR_TO_STACK alignment check to process_dynptr_func
  - 76d16077bef0 bpf: Use memmove for bpf_dynptr_{read,write}
- "Dynptr fixes"[2] series (patchset that addresses this issue)
  - d6fefa1105da bpf: Fix state pruning for STACK_DYNPTR stack slots
  - 79168a669d81 bpf: Fix missing var_off check for ARG_PTR_TO_DYNPTR
  - ef8fc7a07c0e bpf: Fix partial dynptr stack slot reads/writes
  - f8064ab90d66 bpf: Invalidate slices on destruction of dynptrs on stack
  - 379d4ba831cf bpf: Allow reinitializing unreferenced dynptr stack slots
  - f5b625e5f8bb bpf: Combine dynptr_get_spi and is_spi_bounds_valid
  - 1ee72bcbe48d bpf: Avoid recomputing spi in process_dynptr_func

And here's kselftest patches that were backported along the fixes:
- cbd620fc18ca selftests/bpf: Copy over libbpf configs
- dc444be8bae4 selftests/bpf: add extra test for using dynptr data slice after release
- b94fa9f9dcf9 selftests/bpf: Add tests for dynamic pointers parameters in kfuncs
- 26c386ecf021 selftests/bpf: convert dynptr_fail and map_kptr_fail subtests to generic tester
- "Dynptr fixes"[2] series
  - 91b875a5e43b selftests/bpf: convenience macro for use with 'asm volatile' blocks
  - f4d24edf1b92 selftests/bpf: Add dynptr pruning tests
  - ef4810135396 selftests/bpf: Add dynptr var_off tests
  - 011edc8e49b8 selftests/bpf: Add dynptr partial slot overwrite tests
  - ae8e354c497a selftests/bpf: Add dynptr helper tests

1: https://lore.kernel.org/r/20221207204141.308952-1-memxor@gmail.com
2: https://lore.kernel.org/r/20230121002241.2113993-1-memxor@gmail.com

(In reply to Shung-Hsi Yu from comment #5)
> [snip]
> - b239da34203f bpf: Add helper macro bpf_for_each_reg_in_vstate
> - e9e315b4a5de bpf: Move dynptr type check to is_dynptr_type_expected()
> - "Dynptr refactorings"[1] series (dependency)
>   - 6b75bd3d0367 bpf: Refactor ARG_PTR_TO_DYNPTR checks into
> process_dynptr_func
>   - ac50fe51ce87 bpf: Propagate errors from process_* checks in
> check_func_arg
>   - 270605317366 bpf: Rework process_dynptr_func
>   - 184c9bdb8f65 bpf: Rework check_func_arg_reg_off
>   - f6ee298fa140 bpf: Move PTR_TO_STACK alignment check to
> process_dynptr_func
>   - 76d16077bef0 bpf: Use memmove for bpf_dynptr_{read,write}
> - "Dynptr fixes"[2] series (patchset that addresses this issue)
>   - d6fefa1105da bpf: Fix state pruning for STACK_DYNPTR stack slots
>   - 79168a669d81 bpf: Fix missing var_off check for ARG_PTR_TO_DYNPTR
>   - ef8fc7a07c0e bpf: Fix partial dynptr stack slot reads/writes

AFAICT the main fixes are the above three commits, but I've decided to backport the whole series to better match upstream

>   - f8064ab90d66 bpf: Invalidate slices on destruction of dynptrs on stack
>   - 379d4ba831cf bpf: Allow reinitializing unreferenced dynptr stack slots
>   - f5b625e5f8bb bpf: Combine dynptr_get_spi and is_spi_bounds_valid
>   - 1ee72bcbe48d bpf: Avoid recomputing spi in process_dynptr_func
> [snip]

I'll check that the following test passes before marking this as resolved
- f4d24edf1b92 selftests/bpf: Add dynptr pruning tests
- ef4810135396 selftests/bpf: Add dynptr var_off tests
- 011edc8e49b8 selftests/bpf: Add dynptr partial slot overwrite tests
- ae8e354c497a selftests/bpf: Add dynptr helper tests

Confirmed that the following BPF kselftests changed from FAIL to OK once the fixes are applied, reassigning back to security team.

#53/38   dynptr/dynptr_overwrite_ref
#53/39   dynptr/dynptr_read_into_slot
#53/40   dynptr/uninit_write_into_slot
#53/41   dynptr/invalid_data_slices
#53/42   dynptr/dynptr_pruning_overwrite
#53/44   dynptr/dynptr_pruning_type_confusion
#53/45   dynptr/dynptr_var_off_overwrite
#53/46   dynptr/dynptr_partial_slot_invalidate

Hi Shung-Hsi, is it possible to get this fixed in Leap 15.4?

Thanks,
Simon

the problematic bug was not backported to SLES 15 SP4 / Leap 15.4 kernels.

(In reply to Marcus Meissner from comment #17)
> the problematic bug was not backported to SLES 15 SP4 / Leap 15.4 kernels.

Thanks Marcus.

Simon