“模型发现一个内存泄漏”还不够构成漏洞结论。需要知道它看的是哪个commit、走过哪条可达路径、资源究竟归谁释放以及修复后那个失败条件是否真的消失。这里不讲没有仓库与日志支撑的真实驱动战绩。我们先做一份可以核对真值的教学题再说明怎样把它交给GLM审阅。GLM-5.3文档说明了模型ID和推理参数厂商列出的代码或安全基准表现不能代替这道题的实际结果。本文没有调用GLM API。模型官方文档将所有权写在路径旁边设想一个简化的probe流程先获得元数据META再获得环缓冲区RING最后初始化外设。失败时必须逆序归还已经获得的资源。故障点进入清理时拥有的资源正确退出后应剩余元数据申请前失败无无环申请前失败META无后续初始化失败META、RING无正常完成再移除META、RING无下面不是内核模块。它用位标记模拟所有权不申请物理DMA内存也不读取真实设备。broken1时最后一个失败分支故意跳过RING清理broken0走完整清理。#include assert.h #include stdio.h /* Teaching ledger, no kernel APIs or physical DMA allocations. */ enum { META 1, RING 2 }; static unsigned probe(int fail, int broken) { unsigned owned 0; if (fail 1) return owned; owned | META; if (fail 2) goto free_meta; owned | RING; if (fail 3 broken) goto free_meta; /* success immediately follows the normal remove path in this model */ owned ~RING; free_meta: owned ~META; return owned; } int main(void) { for (int fail 0; fail 3; fail) { unsigned bad probe(fail, 1), fixed probe(fail, 0); assert(fixed 0); assert(bad (fail 3 ? RING : 0)); printf(fail%d bad%u fixed%u\n, fail, bad, fixed); } }保存成ownership.c运行cc -stdc11 -Wall -Wextra -Werror -O2 ownership.c -o ownership ./ownership示例在macOS arm64、Apple Clang 21.0.0上执行输出为fail0 bad0 fixed0 fail1 bad0 fixed0 fail2 bad0 fixed0 fail3 bad2 fixed0bad2表示RING这一位还留在所有权台账上不表示真的泄漏了2字节。这个检查只证明教学模型内的路径差异它没有发现任何开源内核中的漏洞。给模型的任务也必须可被否定可以把两个版本匿名为A与B再加入“资源已交给另一个拥有者”这样的合法负例。先固定真值后收集回答避免看到模型结论才改评分标准。提示可以写得很短分析给定函数的资源所有权。只根据所给代码作答。 列出每个return前仍持有的资源以及可达条件。 若所有权转移、调用实现或并发关系缺失写证据不足。 不要把goto标签名字当成已经执行了释放操作。 输出结论、路径、依据行、缺失前提不要生成真实漏洞编号。如果后续确实调用GLM应保存模型ID、推理参数、请求时间、完整输入与原始回答并记录弃答与误报。这些资料齐全后才能说“模型在这组样例上识别了某条错误路径”。结构化输出和更长上下文都不自动变成路径可达性的证明。换成真实驱动以后要补的证据更多用户态示例可以用C11编译但不能据此给内核补丁塞入nullptr或constexpr。访问时的Linux官方语言文档仍描述-stdgnu11及内核自身封装的扩展实际提交须以目标内核树为准。内核语言说明对真实dma_alloc_coherent、设备托管资源、异步回调和错误回滚还要核对对应内核实现与设备生命周期。kmemleak报告的是可能泄漏对象是否跟踪到这类分配、是否有误报需要另外确认。一次echo scan不会替你完成资源所有权论证。kmemleak官方文档我会把一份合格审计记录定义成固定源码、可达失败条件、资源前后状态、修复差异和回归结果。模型回答可以帮助找线索但缺少这些材料时标题就该停在“辅助分析”或“教学实验”。本文不包含API效果、真实漏洞发现或内核实机验证。
