CVE-2024-26798

See a problem?
Please try reporting it to the source first.
Source
https://nvd.nist.gov/vuln/detail/CVE-2024-26798
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-26798.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-26798
Related
Published
2024-04-04T09:15:08Z
Modified
2024-09-11T05:03:32.308466Z
Summary
[none]
Details

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

fbcon: always restore the old font data in fbcondoset_font()

Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vcresize() failed) started restoring old font data upon failure (of vcresize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcondosetfont() performs no restore at all upon failing vcresize().

This can be reproduced by Syzkaller to crash the system on the next invocation of fontget(). It's rather hard to hit the allocation failure in vcresize() on the first fontset(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcongetfont+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: <TASK> confontget drivers/tty/vt/vt.c:4558 [inline] confontop+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vtkioctl drivers/tty/vt/vtioctl.c:474 [inline] vtioctl+0x632/0x2ec0 drivers/tty/vt/vtioctl.c:752 ttyioctl+0x6f8/0x1570 drivers/tty/ttyio.c:2803 vfsioctl fs/ioctl.c:51 [inline] ...

So restore the font data in any case, not only for user fonts. Note the later 'if' is now protected by 'olduserfont' and not 'olddata' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.)

References

Affected packages

Debian:12 / 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.1.82-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

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

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.7.9-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

Ecosystem specific 

{
    "urgency": "not yet assigned"
}