英伟达 CEO 黄仁勋称五年前的 GPU 就像“老酒”：越陈越香，还会涨价

https://www.ithome.com/0/950/065.htm

值得注意的是，价格上涨不仅发生在新产品上，旧一代 GPU 同样受到影响。即使是 4 至 5 年前的产品，目前仍在持续升值。黄仁勋指出，旧 GPU 的涨价速度甚至超过好酒陈化速度，在市场中仍然具有强需求。

知情人士说，美国政府已批准阿里、腾讯、字节、京东等10家中国企业购买H200显卡，每家可买7.5万张。联想、富士康等获准为分销商。英伟达黄仁勋原不在随特朗普访华的企业家范围，以避免见习近平时因芯片限售而尴尬，但特朗普临时决定邀请，让他从阿拉斯加中途登机赴华。
习近平特朗普5月14日上午在人民大会堂会谈，决定将中美定位为“建设性战略稳定关系”。特朗普逐一向习近平介绍随访企业家。习近平说，昨天两国经贸团队达成了总体平衡积极的成果。台独与台海和平水火不容，维护台海和平稳定是中美双方最大公约数，美方务必慎之又慎处理台湾问题。
（路透社，新华社）

美国批准向10家中国公司出售H200芯片，英伟达美股夜盘拉升涨超2%

BlockBeats 消息，5 月 14 日，据路透社报道，三位知情人士透露，美国已允许阿里巴巴、字节跳动、腾讯和京东在内的 10 家中国企业购买英伟达 H200 芯片。联想与富士康等分销企业也能购买。

据 Bitget 数据显示，英伟达美股夜盘短线拉升，现涨超 2%。

原文链接 https://m.theblockbeats.info/flash/345900

This is your reminder to set up a monthly donation for your favorite open-source software.

It doesn't really matter what. Could be the OS you're using right now, could be some application. If we all give a small donation to FreeCAD for example, they might turn into something like Blender today.

It doesn't have to be a lot too, but if you have some spare money, just do it!
It might feel useless but if you won't notice 10 dollars being gone from your bank account, just give it to them. you'll make a real difference

https://www.reddit.com/r/linux/s/99jY94JeMo

Unfixed non-public security issues libexpat/libexpat#1160
https://github.com/libexpat/libexpat/issues/1160

TIL
sysusers.d(5)
u! httpd 404 "HTTP User"

Type u may be suffixed with an "!" ("u!") to create a fully locked account. This is recommended, since logins should typically not be allowed for system users. With or without the exclamation mark an invalid password is set. For "u!", the account is also locked, which makes a difference for non-password forms of authentication, such as SSH or similar.

Added in version 257.

fully locked (instead of just with an invalid password).

.sp_expire = i->locked ? 1 : -1

PyJWT is a JSON Web Token implementation in Python. Prior to 2.12.0, PyJWT does not validate the crit (Critical) Header Parameter defined in RFC 7515 §4.1.11. When a JWS token contains a crit array listing extensions that PyJWT does not understand, the library accepts the token instead of rejecting it. This violates the MUST requirement in the RFC. This vulnerability is fixed in 2.12.0.

2026-03-12

#安全预警 NPM包 node-ipc 出现供应链攻击，请暂停安装。

发生时间:5月14日23:30左右

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

Revisit of Deepin Desktop D-Bus Services after Removal from openSUSE (April 2026)

openSUSE 再次评估 Deepin 桌面组件，结果依然令人失望。虽然官方声称已修复，但审计发现 Backlight Helper 缺少 Polkit 认证，Accounts Service 更是漏洞百出：CreateGuestUser 存在竞态条件，SetHomeDir 可将家目录移至 /root，SetPassword 甚至泄露明文密码并存在 root 提权风险。openSUSE 表示 Deepin 安全文化堪忧，修复效率极低，建议用户谨慎使用，并已降低其审核优先级。

https://security.opensuse.org/2026/04/20/winter-spotlight.html#section-deepin

#aigc

这个问题的迷人之处在于，甚至 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/

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

https://t.me/theblockbeats/176703
还是 V12Sec，但是是区块链

@v12sec:
We originally reported this bug on April 28.
Our AI security tool autonomously found this weeks before the hack happened.
But embargo was broken when they accidentally made a public PR with the fix, before it was deployed to the validator set 🥴
https://x.com/v12sec/status/2055293473423810983/

H200还没到中国，Anthropic先急了：千亿美元抢芯片，转头涨价让开发者买单

Anthropic以中美AI竞争为由发布长文，呼吁进一步收紧芯片出口限制。

========
我已经5h没听到 a\和李彦宏小时候的故事了

原文赏析
https://m.huxiu.com/article/4858714.html

QEMUtiny is a memory corruption vulnerability in QEMU's implementation of CXL (Compute Express Link) Type-3 (Memory Device) device emulation.

1. OOB read: cmd_logs_get_log() treats the CEL log offset as an array index in the memmove() source expression even though the CXL mailbox offset is in bytes.
2. OOB write: cmd_features_set_feature() accepts byte offsets into several small feature write-attribute structures without checking that offset + bytes_to_copy stays inside the selected structure.

poc.c is a working exploit that drives the emulated CXL mailbox from the guest through the device BAR. It depends on offsets for the specific QEMU build and host libc layout. The exploit can be weaponized to work reliably across many QEMU versions using the OOB read to scan memory. However this is out of scope for this PoC.

https://github.com/v12-security/pocs/tree/main/qemu