[단독방어] 분석 — CVE-2026-23463

• 심각도 medium · CVSS 4.7 · EPSS 0.00094 · 악용난이도 hard

동적 FQID(QMAN_FQ_FLAG_DYNAMIC_FQID)가 설정된 상태에서 qman_destroy_fq()와 qman_create_fq()가 동시에 실행되면, fq_table의 인덱스 값이 해제 직후 재할당되어 WARN_ON(fq_table[fq->idx]) 가 발생합니다. 이 레이스는 커널 내부에서만 일어나며 외부 입력을 필요로 하지 않으므로 로컬 권한을 가진 프로세스가 고빈도 fq 생성·삭제를 수행하면 트리거될 수 있습니다.

악용 가능성: 해당 취약점은 AV:L(로컬 접근)·AC:H(높은 난이도)·PR:L(낮은 권한)·UI:N(사용자 개입 없음)이라는 CVSS 벡터를 갖고 있어, 공격자는 동일 시스템 내에서 커널 모듈을 로드하거나 루트 권한을 가진 프로세스를 실행해야 하며, 두 스레드가 qman_destroy_fq()와 qman_create_fq() 사이에 정확히 타이밍을 맞추는 고난도 레이스 컨디션을 재현해야 합니다.
EPSS 값이 0.00094로 매우 낮고 KEV 목록에도 포함되지 않아, 현재까지 실전에서 악용된 사례가 거의 없으며 이론적 위험성에 비해 실제 위협은 제한적이라고 판단됩니다.
공격 표면은 Linux 커널의 soc/fsl/qbman 모듈이 제공하는 QMAN API이며, 특히 qman_release_fqid()·gen_pool_free() 이후 바로 `qman_alloc

WARN_ON 은 커널 패닉(Oops)으로 이어질 가능성이 낮지만, 레이스 상황이 반복되면 시스템 로그에 지속적인 경고가 남으며, 최악의 경우 해당 FQ 구조체가 잘못 초기화돼 네트워크/스토리지 I/O 처리에 오류가 발생할 수 있습니다. 즉, 서비스 가용성 저하 및 디버깅 비용 증가가 주요 위험입니다.

• 동일한 리소스 재사용 레이스를 이용하는 다른 드라이버 버그(예: cgroup‑related race)와 결합하면 권한 상승이나 DoS 로 이어질 수 있습니다.
• 현재 확인된 CVE 번호는 없으며, 본 취약점은 독립적인 레이스이지만 “리소스 재활용 → 상태 검증 부재” 패턴은 다른 커널 서브시스템에서도 나타날 가능성이 있습니다.

1. 커널 로그 기반 탐지
   • 대상 파일: /var/log/kern.log, dmesg 출력, journalctl -k
   • 키워드/패턴:

 1WARN_ON\([^)]*fq_table\[[0-9]+\]\)
 2.*qman_create_fq.*```
 3- 설명: `WARN_ON` 과 `qman_create_fq` 문자열이 동시에 포함된 라인은 레이스 발생 가능성을 직접 나타냅니다.  
 4 
 52. **SIEM 쿼리 예시 (Splunk)**  
 6```spl
 7   index=kernel host=* source="/var/log/kern.log"
 8   ("WARN_ON" AND "fq_table") OR ("qman_create_fq")
 9   | stats count by _time, host, message
10   | where count > 5

• 조건: 1분 내에 동일 호스트에서 경고가 5건 초과 시 알림.

1. BPF/tracepoint 기반 실시간 모니터링
   • 트레이스 포인트: qman_alloc_fqid, qman_release_fqid (fsl_qbman)
   • 의사코드:

 1BPF_HASH(cnt, u32, u64);
 2TRACEPOINT_PROBE(fsl_qbman, qman_alloc_fqid) {
 3    u64 *v = cnt.lookup(&args->cpu);
 4    if (v) (*v)++; else cnt.update(&args->cpu, &(u64){1});
 5    return 0;
 6}
 7// 동일 로직을 release 에도 적용 후, 일정 시간(window) 내 합산 > N이면 경고

• 오탐 튜닝: 정상적인 부하에서는 할당/해제 빈도가 초당 < 2회 정도이므로, 임계값을 “5초 동안 15건 이상” 으로 설정하면 오탐을 크게 감소시킬 수 있습니다.

1. 오탐 시나리오 및 조정
   • 고부하 환경에서 테스트 스크립트가 대량 FQ 생성·삭제를 수행할 경우 동일 패턴이 발생합니다. 이때는 “테스트 모드” 태그(예: kernel.msg_tag=test) 를 로그에 추가하고, SIEM 쿼리에서 해당 태그를 제외하도록 필터링합니다.

🛡️ 완화 방안

1. 커널 로그 레벨 강화
   • sysctl -w kernel.printk="4 4 1 7" 로 WARN 수준 이상만 출력하도록 설정하고, 중앙 로그 수집기로 실시간 알림을 구성합니다.
2. SELinux/AppArmor 정책 추가
   • qman_create_fq 를 호출하는 프로세스가 제한된 서비스(예: containerd)에만 허용되도록 규칙 작성.
3. FQ 재사용 간 최소 지연 삽입
   • 커널 파라미터 fqid_reuse_delay_ms (패치 전 임시 변수) 가 존재한다면 10 ms 이상으로 설정해 레이스 윈도우를 확대합니다.

구현 난이도: 중간 (정책 편집 및 재부팅 필요)
운영 영향: 경고 로그 증가와 약간의 성능 저하(재사용 지연).
검증: auditd 로 qman_create_fq 호출 시점과 qman_release_fqid 사이 간격을 측정하고, 10 ms 이상 유지되는지 확인.

⚖️ 위험도 / 우선순위

• 조치: monitor (모니터링)
• 근거: CVSS=4.7 · non-KEV · EPSS=0.00094 · exploit=hard · in_scope=None