一个整数+1，攻破Linux系统内核！

做个小调查：大家喜欢看这种拟人化的网络安全故事吗？

♥ 581 ↩ 36

典型缓存区溢出，2003年BSD内核那边好像也出了类似的漏洞，也是因为强制类型转换导致的[doge]

♥ 159 ↩ 2

看标题以为是无名小卒在哗众取宠，点进去看清UP的名字发现事情并不简单[doge]

♥ 99 ↩ 4

C语言很多库超级喜欢用int，哪怕是负数完全没有意义的地方

♥ 86 ↩ 15

我本科时上操作系统课，有一次作业就被一个类似的bug卡了好几天。当然我的情况比这简单多了，当时需要防止进程越界访问内存。然而我只考虑了正向越界，并没有考虑恶意程序使用负数反向越界。分数一直是99/100，debug了好几天才发现这个问题。至今印象深刻。

♥ 66 ↩ 4

快去请rust[doge]

♥ 62 ↩ 24

刚dota2的比赛也是因为溢出导致的女王生命值上限锁到了1hp，溢出导致的bug太多了。。。。。。

♥ 56 ↩ 1

这编译器没有报warnning的吗

♥ 32 ↩ 8

我想问一下，经过这么多年的完善，应该没什么漏洞了吧，而且这种类型转换安全问题，现在都非常谨慎了，据说现在的黑客已经都不可能在系统层面找到漏洞黑进去了，而是开始找cpu的漏洞了拿Ring0权限，在过几年可能连cpu的漏洞也没了，就只能靠社会工程学来骗密码了。

♥ 30 ↩ 8

右上角有个莫名其妙的小蓝点，看着好难受

♥ 18 ↩ 4

感觉 C 还是太不安全了，用 Rust 根本就不会有这种问题。图一中数组只能用 usize 类型访问，get 方法保证数组越界不会报错。图二中直接访问，越界会直接报错，虽然程序崩溃了，但恶意代码不会被执行。图三中不转换类型直接访问，直接在编译时期报错了，因为数组只能用 usize 类型访问。 通过这三种情况，我们发现无论程序员是怎样写的代码，都能保证恶意代码不会被执行。

♥ 12 ↩ 56

省流：2013年的漏洞，早已修复

♥ 10

不是哥们你不说我都没看到这个点[辣眼睛]

♥ 9

UP终于更新故事系列啦，还是熟悉的味道[doge]

♥ 8 ↩ 1

对那些信誓旦旦把溢出和越界当特性用的同事[给心心][给心心][给心心]

♥ 7

难怪windows和linux都要引入rust，这样的bug靠人真的很难避免。

♥ 5

这个视频就被我们os老师拿来展示了哈哈哈[微笑][支持][doge_金箍]

♥ 4 ↩ 2

这个漏洞适用于哪些Linux版本[吃瓜]不知道做Android root漏洞可不可行

♥ 4 ↩ 3

u64是64位的，int是32位的，虽然结果的对的，但是过程有问题

♥ 4 ↩ 41