CVE-2024-46704

See a problem?
Source
https://nvd.nist.gov/vuln/detail/CVE-2024-46704
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-46704.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-46704
Related
Published
2024-09-13T07:15:05Z
Modified
2024-09-19T15:49:40.671769Z
Severity
  • 4.7 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

workqueue: Fix spruious data race in _flushwork()

When flushing a work item for cancellation, _flushwork() knows that it exclusively owns the work item through its PENDING bit. 134874e2eee9 ("workqueue: Allow cancelworksync() and disablework() from atomic contexts on BH work items") added a read of @work->data to determine whether to use busy wait for BH work items that are being canceled. While the read is safe when @fromcancel, @work->data was read before testing @from_cancel to simplify code structure:

data = *work_data_bits(work);
if (from_cancel &&
    !WARN_ON_ONCE(data & WORK_STRUCT_PWQ) && (data & WORK_OFFQ_BH)) {

While the read data was never used if !@from_cancel, this could trigger KCSAN data race detection spuriously:

================================================================== BUG: KCSAN: data-race in _flushwork / _flushwork

write to 0xffff8881223aa3e8 of 8 bytes by task 3998 on cpu 0: instrumentwrite include/linux/instrumented.h:41 [inline] _setbit include/asm-generic/bitops/instrumented-non-atomic.h:28 [inline] insertwqbarrier kernel/workqueue.c:3790 [inline] startflushwork kernel/workqueue.c:4142 [inline] _flushwork+0x30b/0x570 kernel/workqueue.c:4178 flush_work kernel/workqueue.c:4229 [inline] ...

read to 0xffff8881223aa3e8 of 8 bytes by task 50 on cpu 1: _flushwork+0x42a/0x570 kernel/workqueue.c:4188 flushwork kernel/workqueue.c:4229 [inline] flushdelayed_work+0x66/0x70 kernel/workqueue.c:4251 ...

value changed: 0x0000000000400000 -> 0xffff88810006c00d

Reorganize the code so that @fromcancel is tested before @work->data is accessed. The only problem is triggering KCSAN detection spuriously. This shouldn't need READONCE() or other access qualifiers.

No functional changes.

References

Affected packages

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.10.7-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3
6.3.1-1~exp1
6.3.2-1~exp1
6.3.4-1~exp1
6.3.5-1~exp1
6.3.7-1~bpo12+1
6.3.7-1
6.3.11-1
6.4~rc6-1~exp1
6.4~rc7-1~exp1
6.4.1-1~exp1
6.4.4-1~bpo12+1
6.4.4-1
6.4.4-2
6.4.4-3~bpo12+1
6.4.4-3
6.4.11-1
6.4.13-1
6.5~rc4-1~exp1
6.5~rc6-1~exp1
6.5~rc7-1~exp1
6.5.1-1~exp1
6.5.3-1~bpo12+1
6.5.3-1
6.5.6-1
6.5.8-1
6.5.10-1~bpo12+1
6.5.10-1
6.5.13-1
6.6.3-1~exp1
6.6.4-1~exp1
6.6.7-1~exp1
6.6.8-1
6.6.9-1
6.6.11-1
6.6.13-1~bpo12+1
6.6.13-1
6.6.15-1
6.6.15-2
6.7-1~exp1
6.7.1-1~exp1
6.7.4-1~exp1
6.7.7-1
6.7.9-1
6.7.9-2
6.7.12-1~bpo12+1
6.7.12-1
6.8.9-1
6.8.11-1
6.8.12-1~bpo12+1
6.8.12-1
6.9.2-1~exp1
6.9.7-1~bpo12+1
6.9.7-1
6.9.8-1
6.9.9-1
6.9.10-1~bpo12+1
6.9.10-1
6.9.11-1
6.9.12-1
6.10-1~exp1
6.10.1-1~exp1
6.10.3-1
6.10.4-1
6.10.6-1~bpo12+1
6.10.6-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}