🇰🇷 한글 설명
Linux 커널의 IPv6 라우팅 코드에서, 게이트웨이가 있는 기존 경로의 RTF_ADDRCONF 플래그를 해제할 때 ECMP 형제 경로 목록과 개수가 일치하지 않는 문제가 있습니다. 이로 인해 이후 ECMP 경로를 추가할 때 커널 BUG_ON이 발생하여 시스템이 중단될 수 있습니다. 수정은 게이트웨이가 없는 경로에서만 해당 플래그를 해제하도록 제한하는 것입니다.
💡 쉬운 설명
IPv6 네트워크 경로를 설정하는 과정에서 커널이 잘못된 내부 상태를 만들어 시스템이 강제로 멈출 수 있는 문제입니다. 권한이 있는 사용자가 특정 네트워크 설정을 반복하면 서비스 중단이 발생할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF
syzbot reported a kernel BUG in fib6_add_rt2node() when adding an IPv6
route. [0]
Commit f72514b3c569 ("ipv6: clear RA flags when adding a static
route") introduced logic to clear RTF_ADDRCONF from existing routes
when a static route with the same nexthop is added. However, this
causes a problem when the existing route has a gateway.
When RTF_ADDRCONF is cleared from a route that has a gateway, that
route becomes eligible for ECMP, i.e. rt6_qualify_for_ecmp() returns
true. The issue is that this route was never added to the
fib6_siblings list.
This leads to a mismatch between the following counts:
- The sibling count computed by iterating fib6_next chain, which
includes the newly ECMP-eligible route
- The actual siblings in fib6_siblings list, which does not include
that route
When a subsequent ECMP route is added, fib6_add_rt2node() hits
BUG_ON(sibling->fib6_nsiblings != rt->fib6_nsiblings) because the
counts don't match.
Fix this by only clearing RTF_ADDRCONF when the existing route does
not have a gateway. Routes without a gateway cannot qualify for ECMP
anyway (rt6_qualify_for_ecmp() requires fib_nh_gw_family), so clearing
RTF_ADDRCONF on them is safe and matches the original intent of the
commit.
[0]:
kernel BUG at net/ipv6/ip6_fib.c:1217!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217
[...]
Call Trace:
<TASK>
fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532
__ip6_ins_rt net/ipv6/route.c:1351 [inline]
ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946
ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571
inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577
sock_do_ioctl+0xdc/0x300 net/socket.c:1245
sock_ioctl+0x576/0x790 net/socket.c:1366
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
📍 영향받는 시스템
패치가 적용되지 않은 Linux 커널 (IPv6 ECMP 라우팅을 사용하는 시스템, 해당 수정 커밋 이전 버전)
⚔️ 공격 벡터
로컬에서 권한을 가진 사용자가 게이트웨이가 있는 IPv6 경로를 추가/삭제하는 ioctl 호출을 조작하여 커널 패닉을 유발
🛡️ 대응 방법
배포판 벤더가 제공하는 최신 커널 보안 업데이트를 적용하고 재부팅
🔧 검증 코드
출력된 커널 버전을 배포판 보안 공지에서 해당 패치가 포함된 버전과 비교하여, 같거나 높으면 패치된 것입니다.