| タイトル | Debian等の複数ベンダの製品における不特定の脆弱性 |
|---|---|
| 概要 | Linuxカーネルにおいて、以下の脆弱性が修正されました。riscv: processに関するカーネルgpリークの問題です。childregsはユーザコンテキストで新しいスレッドに対して有効なレジスタを表します。カーネルスレッドの場合、childregs-gpはswitch_toによってカーネルgpに触れられないため、使用されません。ユーザモードヘルパの場合、gpの値はexecve後やその他の手段によってユーザ空間で観測される可能性があります。[メールスレッドより] "/* Kernel thread */"というコメントはやや不正確で、ユーザモードヘルパスレッドにも使われます。これらのスレッドはユーザプロセス(例:/sbin/initや/proc/sys/kernel/core_patternがパイプの場合)をexecします。このようなスレッドはPF_KTHREADが設定されておらず、exec前でもptraceの対象として有効です。childregsはsyscall実行中のユーザコンテキストであり、少なくとも5通りの方法でユーザ空間から観測可能です。1. kernel_execveは現在整数レジスタをクリアしないため、PID 1やカーネルによって起動された他のユーザプロセスの開始時レジスタ状態は、spがユーザスタック、gpがカーネルの__global_pointer$、その他の整数レジスタはパッチコメント内のmemsetでゼロクリアされています。これはバグですが、本パッチで対処した問題を利用する唯一の方法とは考えにくいです。2. ptrace(PTRACE_GETREGSET): ptraceはexec前のユーザモードヘルパスレッドにPTRACE_ATTACH可能ですが、SIGSTOPの送信を要し、これはユーザ・カーネル境界でのみ発生可能です。3. /proc/*/task/*/syscall: exec完了前のユーザモードヘルパのpt_regsを問題なく読み取れますが、gpは返されるレジスタの一つではありません。4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERFは通常PERF_SAMPLE_REGS_INTR経由のカーネルアドレスアクセスを防ぎますが、本バグによりPERF_SAMPLE_REGS_USER経由でもカーネルアドレスが露出しました。PERF_SAMPLE_REGS_USERはLOCKDOWN_PERF下で許可されています。エクスプロイトコードは試みていません。5. 多くのトレーシングインフラはユーザレジスタへのアクセスを許可していますが、ユーザレジスタへのアクセスがカーネルレジスタへのアクセスを許可しない形で可能かどうかは未調査です。 |
| 想定される影響 | 当該ソフトウェアが扱う全ての情報が外部に漏れる可能性があります。 また、当該ソフトウェアが扱う情報について、書き換えは発生しません。 さらに、当該ソフトウェアが完全に停止する可能性があります。 そして、この脆弱性を悪用した攻撃の影響は、他のソフトウェアには及びません。 |
| 対策 | 正式な対策が公開されています。ベンダ情報を参照して適切な対策を実施してください。 |
| 公表日 | 2024年5月19日0:00 |
| 登録日 | 2026年1月27日17:38 |
| 最終更新日 | 2026年1月27日17:38 |
| CVSS3.0 : 重要 | |
| スコア | 7.1 |
|---|---|
| ベクター | CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H |
| Debian |
| Debian GNU/Linux 10.0 |
| Linux |
| Linux Kernel 4.15 以上 5.10.216 未満 |
| Linux Kernel 5.11 以上 5.15.154 未満 |
| Linux Kernel 5.16 以上 6.1.85 未満 |
| Linux Kernel 6.2 以上 6.6.26 未満 |
| Linux Kernel 6.7 以上 6.8.5 未満 |
| Linux Kernel 6.9 |
| No | 変更内容 | 変更日 |
|---|---|---|
| 1 | [2026年01月27日] 掲載 |
2026年1月27日17:38 |
| 概要 | In the Linux kernel, the following vulnerability has been resolved: riscv: process: Fix kernel gp leakage childregs represents the registers which are active for the new thread [From the email thread] The /* Kernel thread */ comment is somewhat inaccurate in that it is also used childregs is the *user* context during syscall execution and it is observable 1. kernel_execve does not currently clear integer registers, so the starting This is a bug in its own right, but I'm unwilling to bet that it is the only 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread 3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel 5. Much of the tracing infrastructure allows access to user registers. I have |
|---|---|
| 公表日 | 2024年5月19日18:15 |
| 登録日 | 2024年5月19日20:00 |
| 最終更新日 | 2024年11月21日18:21 |