github.com/google/syzkaller@v0.0.0-20251211124644-a066d2bc4b02/pkg/report/README.md (about) 1 # Bugs scoring 2 3 Until triaged we don't really know the bug impact. But we can learn a lot from the bug title. 4 5 Syzbot scoring is based on our understanding of what bug class looks historically more impactful. It allows to 6 prioritize the triaging queue. 7 8 ## Heuristics 9 10 ### KASAN > KMSAN > KCSAN 11 KASAN detected bugs are typically more dangerous than KMSAN detected bugs. And KMSAN detected bugs are typically more 12 dangerous than KCSAN detected bugs. 13 14 ### Use-after-free write > invalid-free(double-free) > use-after-free read. 15 16 ### KASAN write > KASAN read 17 KASAN write indicates an out-of-bounds or use-after-free write operation. Any uncontrolled write to kernel memory is 18 extremely dangerous because it can corrupt data or code pointers, making it a high-value target for exploitation 19 and leading to system compromise. KASAN read indicates an out-of-bounds or use-after-free read. This is generally 20 less critical. It can crash the system (DoS) or leak sensitive data, but it doesn't provide a direct path for an 21 attacker to execute their own code. 22 23 ### Memory Safety bugs > DoS bugs. 24 This heuristic establishes a broad priority between two major classes of bugs based on their ultimate impact. 25 26 Memory Safety bugs: This category includes all the issues mentioned aboveāuse-after-free, double-free, out-of-bounds 27 reads/writes, etc. These are considered more severe because they represent a potential system compromise. A successful 28 exploit can allow an attacker to escalate privileges and gain complete control over the kernel and the entire system. 29 30 DoS bugs (Denial of Service): This category includes bugs like kernel hangs, crashes, or resource exhaustion 31 (e.g., memory leaks). While they are serious because they disrupt system availability, they typically do not allow an 32 attacker to execute code or steal data. The impact is usually temporary and can be resolved by rebooting the system. 33 They disrupt the service but don't compromise its integrity. 34 35 ### Information Leaks > Denial of Service (DoS) 36 Kmsan infoleak and other bugs that leak kernel memory are generally more severe than a typical DoS. These leaks can be 37 used to bypass security mitigations like Kernel Address Space Layout Randomization (KASLR), which makes exploiting 38 other vulnerabilities easier. 39 40 ### Concurrency Issues > Simple DoS 41 Bugs like DataRace and LockdepBug can be more critical than a standard DoS. Data races can lead to unpredictable 42 behavior, including memory corruption, which might be exploitable. 43 44 LockdepBug indicates potential deadlocks, which can cause a more severe system Hang than a resource-exhaustion DoS. 45 46 ### KFENCE reports are high priority 47 KFENCE is a lighter-weight memory safety detector compared to KASAN. While it may have a lower performance overhead, 48 the bugs it finds (use-after-free, out-of-bounds) are of the same high-impact nature as those found by KASAN. 49 Therefore, KFENCE detected bugs should be treated with a similar level of urgency as KASAN reports. 50 51 ### UBSAN reports require careful evaluation 52 The Undefined Behavior Sanitizer (UBSAN) can detect a wide range of issues. Their severity can vary greatly: 53 54 1. A shift-out-of-bounds or array-index-out-of-bounds issue can be very severe if it leads to memory corruption. 55 2. An integer-overflow can also be critical if it results in bypassing security checks and leads to a buffer overflow. 56 3. Other UBSAN issues might be less critical but still indicate latent bugs that could become problematic. 57 58 ### LockdepSleeping in Atomic Context is a critical flaw 59 AtomicSleep is a serious bug that can lead to system-wide hangs and instability. This is because holding a spinlock 60 or being in another atomic context while sleeping can cause deadlocks. 61 62 These are generally more severe than a typical DoS. 63 64 ### Memory Leaks are a form of DoS 65 MemoryLeak bugs are a type of denial of service where the kernel gradually runs out of memory. While generally less 66 severe than memory corruption, a fast memory leak that can be triggered by an unprivileged user can be a high-impact 67 DoS vector. 68 69 ### NULL pointer dereference in reads/writes 70 They may be exploitable (see [proof](https://googleprojectzero.blogspot.com/2023/01/exploiting-null-dereferences-in-linux.html )) 71 but the exploitation probability is not clear. Because of this uncertainty they are put to the bottom of the high 72 priority bugs.