This series fixes three bugs in the sysctl write-buffer replacement path
of __cgroup_bpf_run_filter_sysctl(). It resolves a kvzalloc()/kfree()
mismatch, adds a missing NUL terminator to the replacement string, and
updates a stale return value check to safely restore the replacement
functionality.

Patch Summary:
- patch 1 uses kvfree() for the replaced sysctl write buffer
- patch 2 NUL-terminates the replaced sysctl value
- patch 3 restores sysctl new-value replacement

Changelog:
v1 -> v2:
- added patch 2 to fix an out-of-bounds access in
  bpf_sysctl_set_new_value() by properly NUL-terminating the replaced
  sysctl value buffer.
- reordered patches 1 and 3.

Dawei Feng (3):
  bpf: cgroup: use kvfree() for replaced sysctl write buffer
  bpf: cgroup: NUL-terminate replaced sysctl value
  bpf: cgroup: restore sysctl new-value replacement

 kernel/bpf/cgroup.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
2.34.1

On 5/29/26 11:10 AM, Dawei Feng wrote:
> This series fixes three bugs in the sysctl write-buffer replacement path
> of __cgroup_bpf_run_filter_sysctl(). It resolves a kvzalloc()/kfree()
> mismatch, adds a missing NUL terminator to the replacement string, and
> updates a stale return value check to safely restore the replacement
> functionality.
>
> Patch Summary:
> - patch 1 uses kvfree() for the replaced sysctl write buffer
> - patch 2 NUL-terminates the replaced sysctl value
> - patch 3 restores sysctl new-value replacement
>
> Changelog:
> v1 -> v2:
> - added patch 2 to fix an out-of-bounds access in
>    bpf_sysctl_set_new_value() by properly NUL-terminating the replaced
>    sysctl value buffer.
> - reordered patches 1 and 3.


I think patch 1 and patch 3 should be adjacent in the series.

Why is patch 2 placed between them?

>
> Dawei Feng (3):
>    bpf: cgroup: use kvfree() for replaced sysctl write buffer
>    bpf: cgroup: NUL-terminate replaced sysctl value
>    bpf: cgroup: restore sysctl new-value replacement
>
>   kernel/bpf/cgroup.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>

On Fri, May 29, 2026 at 12:44 PM, Jiayuan Chen wrote:
>I think patch 1 and patch 3 should be adjacent in the series.
>
>Why is patch 2 placed between them?

Hi Jiayuan,

Thanks for the review.

Patch 1 and Patch 2 are actually parallel to each other. They both address
pre-existing issues that would be exposed and triggered once the changes
in Patch 3 are applied.

In a previous iteration, a test bot and another maintainer pointed out
that activating the code path without fixing the underlying issues first
could trigger a kernel panic.

I placed both prerequisite fixes (Patch 1 and Patch 2) before Patch 3.
This ensures that the fixes are already in place before the code path is
activated.

If you prefer a different order, please let me know and I will be happy to
adjust it.

> Change is fine but fixes tag is wrong like the bot said.

Noted. I will correct the Fixes tag in v3.

> I saw a reviewed-by tag given by Emil in previous thread. Pls carry it 
> when sending new verson.

Thanks for catching this. I will make sure to collect and carry Emil's
Reviewed-by tag in the upcoming v3.

Best regards,
Dawei

On Fri May 29, 2026 at 7:37 AM EDT, Dawei Feng wrote:
> On Fri, May 29, 2026 at 12:44 PM, Jiayuan Chen wrote:
>>I think patch 1 and patch 3 should be adjacent in the series.
>>
>>Why is patch 2 placed between them?
>
> Hi Jiayuan,
>
> Thanks for the review.
>
> Patch 1 and Patch 2 are actually parallel to each other. They both address
> pre-existing issues that would be exposed and triggered once the changes
> in Patch 3 are applied.
>
> In a previous iteration, a test bot and another maintainer pointed out
> that activating the code path without fixing the underlying issues first
> could trigger a kernel panic.
>
> I placed both prerequisite fixes (Patch 1 and Patch 2) before Patch 3.
> This ensures that the fixes are already in place before the code path is
> activated.
>
> If you prefer a different order, please let me know and I will be happy to
> adjust it.
>
>> Change is fine but fixes tag is wrong like the bot said.
>
> Noted. I will correct the Fixes tag in v3.
>
>> I saw a reviewed-by tag given by Emil in previous thread. Pls carry it 
>> when sending new verson.
>
> Thanks for catching this. I will make sure to collect and carry Emil's
> Reviewed-by tag in the upcoming v3.
>

Seconding what Jiayuan said in terms of the Fixes: tag. Also feel free
to add my Reviewed-by: on patch 2/3 that IIRC was not present on v1.

> Best regards,
> Dawei