CVE-2024-56575 in Linux
摘要
由 VulDB • 2026-05-30
在 ARM64 架构下，`x17` 寄存器通常用于存储系统调用号或异常向量表中的偏移量。然而，在这个内核崩溃（Oops）日志中，`x17` 的值 `5300326563697665` 看起来像是一个 ASCII 字符串。
让我们解码 `x17` 的值：
``` x17: 5300326563697665 ```
将其按字节分解（大端序解释，因为 ARM64 通常以这种方式显示寄存器值，但这里需要小心，因为内核日志通常以小端序显示内存内容，但寄存器值本身是原始二进制）：
实际上，ARM64 寄存器是 64 位整数。让我们将其转换为 ASCII 字符串。注意：ARM64 是小端序架构，但内核日志中的寄存器值通常以十六进制整数形式显示，而不是内存字节顺序。然而，`x17` 的值 `5300326563697665` 如果直接解释为 ASCII 字符（从低位字节到高位字节，或者反过来），可能会得到有意义的字符串。
让我们尝试将 `5300326563697665` 分解为字节：
- 字节 0 (最低有效字节): `65` -> 'e' - 字节 1: `76` -> 'v' - 字节 2: `69` -> 'i' - 字节 3: `63` -> 'c' - 字节 4: `65` -> 'e' - 字节 5: `32` -> '2' - 字节 6: `00` -> '\0' - 字节 7 (最高有效字节): `53` -> 'S'
所以，`x17` 的值 `53003265697665` 实际上对应于字符串 **"eviec2S"** 或者 **"S2eviec"**，这看起来不太有意义。
等等，让我们重新检查 `x17` 的值：`5300326563697665`
如果我们按小端序解释（即最低有效字节在最左边）： - `65` -> 'e' - `76` -> 'v' - `69` -> 'i' - `63` -> 'c' - `65` -> 'e' - `32` -> '2' - `00` -> '\0' - `53` -> 'S'
这仍然是 "eviec2S"。
但是，如果我们按大端序解释（即最高有效字节在最左边）： - `53` -> 'S' - `00` -> '\0' - `32` -> '2' - `65` -> 'e' - `63` -> 'c' - `69` -> 'i' - `76` -> 'v' - `65` -> 'e'
这得到 "S\02eviec"。
这看起来仍然不太有意义。然而，注意到 `x16` 的值是 `645f676e696c6f6f`，让我们解码它：
- `6f` -> 'o' - `6c` -> 'l' - `69` -> 'i' - `6e` -> 'n' - `67` -> 'g' - `5f` -> '_' - `64` -> 'd'
所以 `x16` 是 "old_ing" 或者 "d_olgin"。
再看 `x15` 的值：`63343a6d726f6674`
- `74` -> 't' - `6f` -> 'o' - `72` -> 'r' - `6d` -> 'm' - `6a` -> ':' - `33` -> '3' - `34` -> '4' - `63` -> 'c'
这得到 "torm:43c"。
这些值看起来像是内存地址或指针被错误地解释为 ASCII 字符串。更有可能的是，这些寄存器值指向了某些数据结构，而崩溃发生在 `genpd_runtime_suspend` 函数中。
### 关键分析
1. **崩溃位置**: 崩溃
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.