Linux 커널에서는 다음 취약점이 해결되었습니다. RDMA/iwcm: work_list를 제거하여 작업 대기열 목록 손상 수정 커밋 e1168f0("RDMA/iwcm: cm_event_handler() 단순화") 작품 제출 로직을 무조건 호출하도록 변경했습니다. queue_work()는 queue_work()가 작업이 이미 보류 중인 경우 아무런 효과가 없습니다. 문제는 iwcm_work 구조체의 사용 가능한 목록이 사용됩니다(이 경우 struct work_struct가 내장되어 있으므로 queue_work()를 호출할 때마다 기본적으로는
Linux 커널에서는 다음 취약점이 해결되었습니다.
RDMA/iwcm: work_list를 제거하여 작업 대기열 목록 손상 수정
커밋 e1168f0("RDMA/iwcm: cm_event_handler() 단순화") 작품 제출 로직을 무조건 호출하도록 변경했습니다. queue_work()는 queue_work()가 작업이 이미 보류 중인 경우 아무런 효과가 없습니다. 문제는 iwcm_work 구조체의 사용 가능한 목록이 사용됩니다(이 경우 struct work_struct가 내장되어 있으므로 queue_work()를 호출할 때마다 기본적으로 고유하므로 실제로 작업을 대기열에 넣습니다.
이로 인해 work_list를 탐색하는 작업 핸들러에 문제가 발생합니다. 항목을 처리하기 위해 비어 있을 때까지. 이는 단일 작업 핸들러를 실행하면 항목 N+1을 처리하고 해제할 수 있습니다. 실제 작업 대기열 항목이 아직 남아 있는 동안 사용 가능한 목록으로 돌아갑니다. 대기 중입니다. 그런 다음 재사용(INIT_WORK...)되어 다음과 같은 결과가 발생할 수 있습니다. 작업 대기열 논리의 목록 손상입니다.
work_list를 제거하여 이 문제를 해결하세요. 작업 대기열은 이미 우리를 위해 이 일을 합니다.
이는 스트레스를 받을 때 관찰된 다음 오류를 수정합니다. iWARP 모드의 Intel E830에서 ucmatose로 테스트:
[ 151.465780] list_del 손상. next->prev는 ffff9f0915c69c08이어야 하지만 ffff9f0a1116be08이었습니다. (다음=ffff9f0a15b11c08) [ 151.466639] ------------[ 여기에서 잘라내기 ]------------ [ 151.466986] lib/list_debug.c:67의 커널 버그! [ 151.467349] 이런: 잘못된 opcode: 0000 [#1] SMP NOPTI [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 오염되지 않음 6.19.0-rc4+ #1 PREEMPT(자발적) [ 151.468466] 하드웨어 이름: QEMU Ubuntu 24.04 PC(i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] 작업 대기열: 0x0(iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] 코드: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] 통화 추적: [ 151.476331] <태스크> [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] 작업자_스레드+0x125/0x260 [151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [151.478671] ? __pfx_kthread+0x10/0x10 [151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103]
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도 | 98.00 |
| 악용 신호(추가 악용신호 없음) | ×1.00 |
| VPI | 98.00 |
VPI 공식 vpi-v1 기준