cve/2024/CVE-2024-58085.md

19 lines
1.3 KiB
Markdown
Raw Normal View History

2025-09-29 21:09:30 +02:00
### [CVE-2024-58085](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-58085)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=blue)
### Description
In the Linux kernel, the following vulnerability has been resolved:tomoyo: don't emit warning in tomoyo_write_control()syzbot is reporting too large allocation warning at tomoyo_write_control(),for one can write a very very long line without new line character. To fixthis warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,for practically a valid line should be always shorter than 32KB where the"too small to fail" memory-allocation rule applies.One might try to write a valid line that is longer than 32KB, but suchrequest will likely fail with -ENOMEM. Therefore, I feel that separatelyreturning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.
### POC
#### Reference
No PoCs from references.
#### Github
- https://github.com/w4zu/Debian_security