ACK: [SRU][J:linux][PATCH 0/1] CVE-2024-46787
Emil Renner Berthing
emil.renner.berthing at canonical.com
Wed Jun 11 14:21:32 UTC 2025
Acked-by: Emil Renner Berthing <emil.renner.berthing at canonical.com>
Philip Cox wrote:
> CVE-2024-46787
>
> SRU Justification:
>
> [Impact]
> In the Linux kernel, the following vulnerability has been resolved:
> userfaultfd: fix checks for huge PMDs Patch series
> “userfaultfd: fix races around pmd_trans_huge() check”.
>
> The pmd_trans_huge() check is racy and can lead to a
> BUG_ON() (if you hit the right two race windows), or on older
> kernels (before 6.5), you’d just have to win a single fairly wide
> race to hit this.
>
>
> [Backport]
> Fixed in upstream commit 71c186efc1b2cf1aeabfeff3b9bd5ac4c5ac14d8
>
> The patch does not apply clean due to the fact pmd_read_atomic()
> was renamed to pmdp_get_lockless() in upstream commit
> dab6e717429e5ec795d558a0e9a5337a1ed33a3d.
>
> I did not pick dab6e717429e as a prerequesit for this change
> because it does not apply cleanly either, and would require
> more changes to be picked, further increasing the regression risk.
>
> I strongly feel that is much safer resolve the cherry-pick merge
> conflict by renaming pmdp_get_lockless() to pmd_read_atomic()
> especially in the ESM kernels.
>
>
> [Test]
> compile and boot tested.
>
> [What could go wrong]
> The main risk would be that further cherry-picks may have merge
> conflicts due to the new changes, and may have incorrectly resolved
> merge conflicts. This shold be minimal, and caught by code review,
> but the risk does exist due to the fact that this change has not
> been merged into the stable branches that these backports are
> targetting.
>
> --
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
More information about the kernel-team
mailing list