Nginx 被发现一个存在18年的内存损坏漏洞，可导致远程代码执行，利用门槛低

漏洞存在于每个通用发行版都会包含的rewrite模块 ngx_http_rewrite_module ，影响开原版本Nginx 0.6.27至最近的1.30.0版本，在计算目标缓冲区大小时，使用的是原始字节长度，但在实际写入时，却进行了 URL 转义（ ⁠+⁠ , ⁠%⁠ , ⁠&⁠ 等字符会扩展为 3 倍长度），溢出长度可控导致堆喷射

建议用户尽快更新至 1.30.1 / 1.31.0 版本

Ref: https://depthfirst.com/nginx-rift

From: Linus Torvalds <torvalds-AT-linuxfoundation.org>
To: Willy Tarreau <w-AT-1wt.eu>
Subject: Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug
Date: Wed, 06 May 2026 08:46:07 -0700
Message-ID: <CAHk-=wi6z5BGUUT2p+=qrJg+obom8VnCo3MqB=7xp3Gw+UMMkg@mail.gmail.com>
Cc: greg-AT-kroah.com, leon-AT-kernel.org, security-AT-kernel.org, Jonathan Corbet <corbet-AT-lwn.net>, skhan-AT-linuxfoundation.org, workflows-AT-vger.kernel.org, linux-doc-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org, Greg KH <gregkh-AT-linuxfoundation.org>

I actually think we may want to go further than this.

I think we should simply make it a rule that "a 'security' bug that is found by AI is public".

Now, I may be influenced by that "my inbox is a disaster during the merge window" thing, but I do think this is pretty fundamental: if somebody finds a bug with more or less standard AI tools (ie we're not talking magical special hardware and nation-state level efforts), then that bug pretty much by definition IS NOT SECRET.

So why should be consider it special and have it be on the security list?

Yes, yes, I know - some people think that "security bugs are special". And I've been on the record before calling that opinion special - in the short bus sense.

Bugs are bugs. And not having them in public only makes them harder to deal with.

Do we want to make bugs with potential security impact harder to deal with? No. No, we really don't.

So I claim that the only reason for a security list is the non-public nature of the bug and the whole "responsible disclosure" argument.

But that argument is complete and utter garbage in the face of some mostly automated AI discovery (now, that argument is mostly a fiction in the first place, but I am not going to argue with people who have vested interest in making their special patches "security bugs").

To recap - I think this "document the scope of security bugs" is good, but I think we should go even further, and just document the fact that anything found by regular AI tools should just always go to public lists and is simply not special.

Linus

https://lore.kernel.org/all/CAHk-=wi6z5BGUUT2p+=qrJg+obom8VnCo3MqB=7xp3Gw+UMMkg@mail.gmail.com/

原文链接

闲鱼新规 6 月 1 日起实施，严格区分商家与闲置卖家

闲鱼新增《闲鱼社区经营性行为界定与管理规范》，将于 6 月 1 日生效，综合评估交易物品的性质、来源、数量、价格、频率等，明确经营性卖家认定标准。若卖家使用“一手货源”“七日无理由退货”等经营性描述，且售出商品超 30 件、品类少于 3 类、同款商品反复售出超 5 次、年交易超 104 笔、月成交超 3 笔、年销售额超 10 万元，即被认定为经营性卖家。

被认定的卖家需依法登记并提交营业执照等，履行七日无理由退货等经营者义务。收藏品、潮玩潮鞋、搬家或明星网红身份等导致的频繁交易，平台将单独判定。

Vista 看天下

🌸 在花频道 · 茶馆讨论 · 投稿通道

经群友提醒, 认定标准中各项条件需同时满足才会被判定为商家

帅, otto, 帅!

ssh-keysign-pwn: Steal SSH host private keys and /etc/shadow via the ptrace_may_access mm-NULL bypass + pidfd_getfd. Pre-31e62c2ebbfd kernels.

With ssh-keysign-pwn, unprivileged users are able to read root-owned files. That affects all Linux kernel releases up through today's latest Linux Git state as of earlier today.

__ptrace_may_access() skips the dumpable check when task->mm == NULL. do_exit() runs exit_mm() before exit_files() — no mm, fds still there. pidfd_getfd(2) succeeds in that window when the caller's uid matches the target's.

Reported by Qualys and fixed by the mainline Linux kernel earlier today. This patch to adjust the kernel's ptrace behavior is what fixes the issue.

Jann Horn flagged the FD-theft shape in October 2020.

More details on ssh-keysign-pwn can be found via this GitHub repository.

https://www.phoronix.com/news/Linux-ssh-keysign-pwn

内核的 __ptrace_may_access() 通过任务的 mm 结构体内容判定一个进程是否有权限 ptrace 另一个进程, 但 exit_mm() 析构一个进程时会将 task.mm 置为 NULL, 此时 __ptrace_may_access() 会跳过该检查，但仍然会检查 uid/gid 一致性
选用 drop privilege 前会打开受限文件，且至析构时不关闭之的 victim，利用依赖 __ptrace_may_access() 进行权限检查的 pidfd_getfd() race 进程退出时 mm 置为空而 fd 尚未清空的时机，成功时即可得到敏感文件的 fd。

好了，花些時間去做點有趣的負責任披露，不要再到处挖洞了！

这个问题的迷人之处在于，甚至 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/Pine.LNX.4.33.0208011613440.1315-100000@penguin.transmeta.com/

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

在 CA 老师安利下一口气看完了来自深圳来自深渊的第一季和剧场版
第一季感觉还好, 剧场版我真的想说还有人类吗
人类在哪里
感觉有一种报复社会的美, 这种故事对我还是太超前了

san 值掉完了

根据《名侦探柯南》剧场版推特于 2026 年 5 月 15 日发布的公告，声优山崎和佳奈已于 2026 年 4 月 18 日因病辞世，其曾担任《名侦探柯南》系列作品中毛利兰一角的配音。

公告原文 https://www.ytv.co.jp/conan/pdf/conan_0515.pdf
《名侦探柯南》剧场版推特账号（劇場版名探偵コナン【公式】）所发布的推文 https://x.com/conan_movie/status/2055121457055985717

前几天修正了一些这篇文章中的事实性错误, 补了一些缺漏的内容

btw, 目前我的博客已经换到 blog.ziyao.cc 了, 预计会长期使用这个域名.

成功被困电梯了 哈哈 等救援ing

要开始争抢氧气了 #逆转裁判梗