Latest Linux 6.19 Code Fixes Rust Binder Driver, Adds Intel Nova Lake Point S To MEI
([Linux Kernel] 6 Hours Ago
char/misc)
- Reference: 0001605525
- News link: https://www.phoronix.com/news/Linux-6.19-rc5-char-misc
- Source link:
Ahead of the imminent Linux 6.19-rc5 release, the char/misc pull request was merged earlier today with a notable fix to the Rust Binder driver as well as adding the Intel Nova Lake Point S device ID to the MEI driver.
Today's char/misc merge brings a fix for the Rust Binder driver. Google's Rust Binder driver [1]debuted in the upstream Linux 6.18 kernel as an alternative to the existing C-based Binder driver in the kernel used by Android.
That Rust Binder driver led to [2]the first CVE being assigned to the kernel's Rust code . Now there is another fix to the Rust Binder driver due to a mishap when updating the Rust Binder driver for its Linux 6.18 mainlining.
Alice Ryhl of Google [3]explained in the patch last month:
"When forward-porting Rust Binder to 6.18, I neglected to take commit fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") into account, and apparently I did not end up running the shrinker callback when I sanity tested the driver before submission. This leads to crashes like the following:
============================================
WARNING: possible recursive locking detected
6.18.0-mainline-maybe-dirty #1 Tainted: G IO
--------------------------------------------
kswapd0/68 is trying to acquire lock:
ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230
but task is already holding lock:
ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&l->lock);
lock(&l->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kswapd0/68:
#0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160
#1: ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20
#2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230
To fix this, remove the spin_lock() call from rust_shrink_free_page()."
Dropping one (unsafe) line of Rust code avoids this crash. The patch is merged today for Linux 6.19-rc5 and is also marked for back-porting to the stable Linux 6.19 kernel.
The other notable bit with today's [4]char/misc pull is adding Nova Lake S support to the Intel Management Engine Interface "MEI" driver. As it's just a new device ID and no other driver changes needed, it's fine for this late-stage of the Linux 6.19 cycle as it doesn't risk regressing existing hardware support.
[1] https://www.phoronix.com/news/Rust-Binder-For-Linux-6.18
[2] https://www.phoronix.com/news/First-Linux-Rust-CVE
[3] https://lists.openwall.net/linux-kernel/2025/12/02/759
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9c7ef209cd0f7c1a92ed61eed3e835d6e4abc66c
Today's char/misc merge brings a fix for the Rust Binder driver. Google's Rust Binder driver [1]debuted in the upstream Linux 6.18 kernel as an alternative to the existing C-based Binder driver in the kernel used by Android.
That Rust Binder driver led to [2]the first CVE being assigned to the kernel's Rust code . Now there is another fix to the Rust Binder driver due to a mishap when updating the Rust Binder driver for its Linux 6.18 mainlining.
Alice Ryhl of Google [3]explained in the patch last month:
"When forward-porting Rust Binder to 6.18, I neglected to take commit fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") into account, and apparently I did not end up running the shrinker callback when I sanity tested the driver before submission. This leads to crashes like the following:
============================================
WARNING: possible recursive locking detected
6.18.0-mainline-maybe-dirty #1 Tainted: G IO
--------------------------------------------
kswapd0/68 is trying to acquire lock:
ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230
but task is already holding lock:
ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&l->lock);
lock(&l->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kswapd0/68:
#0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160
#1: ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20
#2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230
To fix this, remove the spin_lock() call from rust_shrink_free_page()."
Dropping one (unsafe) line of Rust code avoids this crash. The patch is merged today for Linux 6.19-rc5 and is also marked for back-porting to the stable Linux 6.19 kernel.
The other notable bit with today's [4]char/misc pull is adding Nova Lake S support to the Intel Management Engine Interface "MEI" driver. As it's just a new device ID and no other driver changes needed, it's fine for this late-stage of the Linux 6.19 cycle as it doesn't risk regressing existing hardware support.
[1] https://www.phoronix.com/news/Rust-Binder-For-Linux-6.18
[2] https://www.phoronix.com/news/First-Linux-Rust-CVE
[3] https://lists.openwall.net/linux-kernel/2025/12/02/759
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9c7ef209cd0f7c1a92ed61eed3e835d6e4abc66c