Bug 2301465 (CVE-2024-42102)

Summary: CVE-2024-42102 kernel: Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dfreiber, drow, jburrell, vkumar
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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 Doc Type: If docs needed, set a value
Doc Text:
A vulnerability was found in the wb_dirty_limits() function in the Linux kernel, where a removed (u64) cast in the dtc->wb_thresh * dtc->bg_thresh operation can result in multiplication overflow on 32-bit architectures. This issue could lead to memory corruption or performance issues.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2301760    
Bug Blocks:    

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