CVE-2024-35934 in Linux
Tóm tắt
Bởi VulDB • 24/05/2026
Trong đoạn log bạn cung cấp, đây là một **deadlock** hoặc **lock contention** nghiêm trọng liên quan đến `rtnl_mutex` và `pernet_ops_rwsem` trong kernel Linux, cụ thể là khi tạo namespace mạng mới (`copy_net_ns`) và khởi tạo SMC (Shared Memory Communications).
### Phân tích vấn đề
1. **Các lock bị giữ:** * `pernet_ops_rwsem`: Được giữ trong `copy_net_ns` (net/core/net_namespace.c:491). Đây là semaphore đọc/ghi bảo vệ danh sách các pernet operations (các thao tác liên quan đến namespace). * `rtnl_mutex`: Được giữ trong `smc_pnet_net_init` (net/smc/smc_pnet.c:878) và `smc_pnet_create_pnetids_list` (net/smc/smc_pnet.c:809). Đây là mutex bảo vệ các thay đổi đối với routing/netlink.
2. **Nguyên nhân gây deadlock:** * Nhiều tiến trình (`syz-executor.0`, `.3`, `.4`, `.1`, `.2`) đang cố gắng tạo namespace mạng mới (`copy_net_ns`) đồng thời. * Trong quá trình tạo namespace, kernel gọi `smc_pnet_net_init` (một pernet init function). * Hàm `smc_pnet_net_init` cố gắng lấy `rtnl_mutex`. * Tuy nhiên, `rtnl_mutex` có thể đang bị giữ bởi một tiến trình khác đang thực hiện thao tác netlink/routing, hoặc có thể có một vòng lặp phụ thuộc lock (lock ordering violation) giữa `pernet_ops_rwsem` và `rtnl_mutex`. * **Điểm mấu chốt:** `copy_net_ns` đang giữ `pernet_ops_rwsem` (ở chế độ write, vì đang tạo namespace mới) và trong khi đó, nó gọi các pernet init functions (như `smc_pnet_net_init`). Nếu `smc_pnet_net_init` cố gắng lấy `rtnl_mutex`, và `rtnl_mutex` đang bị giữ bởi một tiến trình khác đang chờ `pernet_ops_rwsem` (hoặc một tiến trình khác đang giữ `rtnl_mutex` và chờ `pernet_ops_rwsem`), thì deadlock xảy ra.
3. **Tại sao lại có nhiều tiến trình cùng giữ lock?** * Syzkaller (công cụ fuzzing kernel) thường tạo ra nhiều tiến trình song song để tìm ra race conditions. * Việc nhiều tiến trình cùng gọi `clone(CLONE_NEWNET)` (tạo namespace mạng mới) dẫn đến việc nhiều tiến trình cùng cố gắng lấy `pernet_ops_rwsem` và sau đó là `rtnl_mutex` trong các pernet init functions.
### Giải pháp khắc phục
#### 1. Kiểm tra thứ tự lấy lock (Lock Ordering) Kernel yêu cầu các lock phải được lấy theo một thứ tự nhất định để tránh deadlock. Trong trường hợp này, cần đảm bảo rằng: * Không bao giờ lấy `rtnl_mutex` trong khi đang giữ `pernet_ops_rwsem` (hoặc ngược lại) nếu có thể tránh được. * Nếu bắt buộc phải lấy cả hai, phải đảm bảo thứ tự cố định: ví dụ, luôn lấy `pernet_ops_rwsem` trước, rồi mới lấy `rtnl_mutex`.
#### 2. Tối ưu hóa `smc_pnet_net_init` * Kiểm tra xem `smc_pnet_net_init` có thực sự cần `rtnl_mutex` không? * Nếu chỉ cần đọc dữ liệu, có thể sử dụng `rcu_read_lock()` thay vì `rtnl_mutex`. * Nếu cần ghi, hãy xem xét việc trì hoãn việc ghi vào `rtnl` cho đến khi thoát khỏi vùng bảo vệ bởi `pernet_ops_rwsem`.
#### 3. Sử dụng `try_rtnl_lock()` hoặc `rtnl_trylock()` * Thay vì `rtnl_lock()` (chặn chờ), có thể dùng `rtnl_trylock()` để thử lấy lock. Nếu không lấy được, có thể bỏ qua hoặc thử lại sau, tránh deadlock.
#### 4. Giảm thiểu thời gian giữ lock * Rút ngắn thời gian giữ `pernet_ops_rwsem` và `rtnl_mutex` bằng cách di chuyển các thao tác không cần thiết ra ngoài vùng bảo vệ.
#### 5. Patch kernel (nếu là lỗi trong kernel) Nếu đây là lỗi trong kernel upstream, bạn có thể cần submit một patch để sửa thứ tự lấy lock hoặc tối ưu hóa `smc_pnet_net_init`.
### Ví dụ về cách sửa (giả định)
Nếu `sm
If you want to get best quality of vulnerability data, you may have to visit VulDB.