CVE-2026-43385

Linux 커널에서는 다음 취약점이 해결되었습니다.

net: 스레드 busypoll에서 rcu_tasks 정지 문제 수정

NIC 드라이버를 디버깅하던 중 NIC 드라이버를 활성화하면 스레드 busypoll, bpftrace가 시작 시 중단됩니다. dmesg는 다음을 보여주었습니다:

rcu_tasks_wait_gp: rcu_tasks 유예 기간 번호 85(부팅 이후)는 10658지피가 지났습니다. rcu_tasks_wait_gp: rcu_tasks 유예 기간 번호 85(부팅 이후)는 40793지피가 지났습니다. rcu_tasks_wait_gp: rcu_tasks 유예 기간 번호 85(부팅 이후)는 131273지피가 지났습니다. rcu_tasks_wait_gp: rcu_tasks 유예 기간 번호 85(부팅 이후)는 402058지피가 되었습니다. 정보: rcu_tasks가 작업 중단을 감지했습니다. 00000000769f52cd: .N nvcsw: 2/2 홀드아웃: 1 유휴_cpu: -1/64 작업:napi/eth2-8265 상태:R 실행 중인 작업 스택:0 pid:48300 tgid:48300 ppid:2 task_flags:0x208040 플래그:0x00004000 통화 추적: <과제> ? napi_threaded_poll_loop+0x27c/0x2c0 ? __pfx_napi_threaded_poll+0x10/0x10 ? napi_threaded_poll+0x26/0x80 ? kthread+0xfa/0x240 ? __pfx_kthread+0x10/0x10 ? ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ? ret_from_fork_asm+0x1a/0x30

원인은 스레드 busypoll에서 메인 루프가 다음 위치에 있기 때문입니다. napi_threaded_poll_loop가 아닌 napi_threaded_poll입니다. 후자는 루프 내에서 두 번 이상 반복되는 경우가 거의 없습니다. 에 대한 napi_threaded_poll_loop 내부의 rcu_softirq_qs_periodic을 보고합니다. qs 상태, last_qs는 100ms 뒤에 있어야 하며 이런 일은 일어날 수 없습니다. napi_threaded_poll_loop는 스레드 busypoll에서 거의 반복되지 않기 때문입니다. napi_threaded_poll_loop가 호출될 때마다 last_qs는 다음으로 재설정됩니다. 최신 지피.

이 패치는 스레드 busypoll에서 last_qs가 저장되도록 변경됩니다. 외부 napi_threaded_poll 및 busy_poll_last_qs 여부 NULL이면 napi_threaded_poll_loop가 호출되는지 여부를 나타냅니다. 바쁜 설문 조사. 이런 식으로 last_qs는 최신 jiffies로 재설정되지 않습니다. napi_threaded_poll_loop의 각 호출.