Bug 2301465 (CVE-2024-42102) - CVE-2024-42102 kernel: Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
Summary: CVE-2024-42102 kernel: Revert "mm/writeback: fix possible divide-by-zero ...
Keywords:
Status: NEW
Alias: CVE-2024-42102
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On: 2301760
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-07-30 08:21 UTC by OSIDB Bzimport
Modified: 2024-10-18 14:53 UTC (History)
4 users (show)

Fixed In Version: kernel 4.19.318, kernel 5.4.280, kernel 5.10.222, kernel 5.15.163, kernel 6.1.98, kernel 6.6.39, kernel 6.9.9, kernel 6.10
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2024:6650 0 None None None 2024-09-12 14:28:42 UTC
Red Hat Product Errata RHSA-2024:6267 0 None None None 2024-09-04 00:25:42 UTC
Red Hat Product Errata RHSA-2024:6268 0 None None None 2024-09-04 00:11:44 UTC
Red Hat Product Errata RHSA-2024:6567 0 None None None 2024-09-11 01:01:14 UTC

Description OSIDB Bzimport 2024-07-30 08:21:07 UTC
In the Linux kernel, the following vulnerability has been resolved:

Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"

Patch series "mm: Avoid possible overflows in dirty throttling".

Dirty throttling logic assumes dirty limits in page units fit into
32-bits.  This patch series makes sure this is true (see patch 2/2 for
more details).


This patch (of 2):

This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.

The commit is broken in several ways.  Firstly, the removed (u64) cast
from the multiplication will introduce a multiplication overflow on 32-bit
archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the
default settings with 4GB of RAM will trigger this).  Secondly, the
div64_u64() is unnecessarily expensive on 32-bit archs.  We have
div64_ul() in case we want to be safe & cheap.  Thirdly, if dirty
thresholds are larger than 1<<32 pages, then dirty balancing is going to
blow up in many other spectacular ways anyway so trying to fix one
possible overflow is just moot.

Comment 1 Mauro Matteo Cascella 2024-07-30 18:19:04 UTC
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2024073019-CVE-2024-42102-bcee@gregkh/T

Comment 2 Mauro Matteo Cascella 2024-07-30 18:19:25 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 2301760]

Comment 6 errata-xmlrpc 2024-09-04 00:11:43 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Extended Update Support

Via RHSA-2024:6268 https://access.redhat.com/errata/RHSA-2024:6268

Comment 7 errata-xmlrpc 2024-09-04 00:25:41 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.2 Extended Update Support

Via RHSA-2024:6267 https://access.redhat.com/errata/RHSA-2024:6267

Comment 8 errata-xmlrpc 2024-09-11 01:01:13 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2024:6567 https://access.redhat.com/errata/RHSA-2024:6567


Note You need to log in before you can comment on or make changes to this bug.