环境配置：

• 内核版本 v5.14.16
• 设置 CONFIG_SLAB_FREELIST_HARDENED、CONFIG_SLAB_FREELIST_RANDOM 编译选项

问题描述：
目前存在 kmalloc-128 空闲链表：

• freelist -> A -> B -> C -> D -> ......
• next 指针存放在 object + 0x40 处，即 offset = 0x40

A 的地址和部分内容如下：

B 的地址和部分内容如下：

C 的地址和部分内容如下：

D 的地址和部分内容如下：

next 指针的加密方式为:

但是这里调试发现一个问题：ptr 和 ptr_addr 的高两字节都是 0xffff，所以最后异或出来 ptr ^ ptr_addr ^ cookie 的高两字节应该就是 cookie 的高两字节，也就是说每个 next 指针的高两字节都是相同的，但是这里 A 的 next = 0x1d947f537ffab314 高两字节为 0x1d94，B 的 next = 0x1d987f537ffaba14 高两字节为 0x1d98，这两者并不相同

不仅如此，对于 kmalloc-128，在我的环境下，其同一个 slab cache 中高 52 bit 是相同的，所以加密后的指针高 52 bit 应该也是相同的，其就是 cookie 的高 52 bit，但是这里异或出来发现高 52 bit 并非完全相同（大部分是相同的）

自己的探索：
我按照 ptr ^ ptr_addr ^ cookie 的方式去恢复 cookie，发现同一个 slab cache 利用不同堆块恢复出来的居然不同？按照源码来看，这个 random(cookie) 是针对 slab cache 的，所以这里选择不同堆块恢复出来的应该是一样的才对

笔者的问题：
请问在设置了 CONFIG_SLAB_FREELIST_HARDENED 编译选项下 next 指针的加密方式到底是什么？为什么按照源码中的加密逻辑去推理调试却得到不同的 cookie 并且高两字节居然不相同
========================= 后续 ===========================
自己解决了

又审计了一下源码，发现源码中对 ptr_addr 进行了一个 swab 操作很奇怪（之前眼睛瞎了，自动忽视了），跟进去发现其定义如下：主要看 64位的

可以看到会进行字节上的交换....感觉这里应该就是防止堆块地址大量字节相同导致泄漏 cookie 而加的保护，也就是上面说的异或出来的值高 52 bit 就是 cookie 值

[培训]内核驱动高级班，冲击BAT一流互联网大厂工 作，每周日13:00-18:00直播授课