Answer in brief
CVE-2026-74398 records a Unknown severity vulnerability in ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-74398 records a Unknown severity vulnerability in ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <47b05836705b63dab93d9ac7c69a3a507375ef80 || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <d21be7d051012c6b572fa4e3334443c250216f7b || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <875c284c0f98b042bb97abad460f63a24c977f88 || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <8ed0ce9ea58d677d1bac92614ee5f60f8ea57363 || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <3bdc86d89fd6c6523753fa6f42fcfaf30ee699cb || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <b61af0268e3d1308c466bf0be5dced844eafc1ef || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <e889aa99ad3ed48bb0ddcff6475b17542532d18b || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <627ac78f2741e2ebd2225e2e953b6964a8a9182f || 835b474b8f70fa68d68abffad37378e92f661802 || >=3.10.105 <3.11 | 47b05836705b63dab93d9ac7c69a3a507375ef80, d21be7d051012c6b572fa4e3334443c250216f7b, 875c284c0f98b042bb97abad460f63a24c977f88, 8ed0ce9ea58d677d1bac92614ee5f60f8ea57363, 3bdc86d89fd6c6523753fa6f42fcfaf30ee699cb, b61af0268e3d1308c466bf0be5dced844eafc1ef, e889aa99ad3ed48bb0ddcff6475b17542532d18b, 627ac78f2741e2ebd2225e2e953b6964a8a9182f, 3.11 |
| Linux/Linuxgeneric | 3.14 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <47b05836705b63dab93d9ac7c69a3a507375ef80 || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <d21be7d051012c6b572fa4e3334443c250216f7b || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <875c284c0f98b042bb97abad460f63a24c977f88 || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <8ed0ce9ea58d677d1bac92614ee5f60f8ea57363 || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <3bdc86d89fd6c6523753fa6f42fcfaf30ee699cb || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <b61af0268e3d1308c466bf0be5dced844eafc1ef || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <e889aa99ad3ed48bb0ddcff6475b17542532d18b || >=c15b1ccadb323ea50023e8f1cca2954129a62b51 <627ac78f2741e2ebd2225e2e953b6964a8a9182f || 835b474b8f70fa68d68abffad37378e92f661802 || >=3.10.105 <3.11 | 47b05836705b63dab93d9ac7c69a3a507375ef80, d21be7d051012c6b572fa4e3334443c250216f7b, 875c284c0f98b042bb97abad460f63a24c977f88, 8ed0ce9ea58d677d1bac92614ee5f60f8ea57363, 3bdc86d89fd6c6523753fa6f42fcfaf30ee699cb, b61af0268e3d1308c466bf0be5dced844eafc1ef, e889aa99ad3ed48bb0ddcff6475b17542532d18b, 627ac78f2741e2ebd2225e2e953b6964a8a9182f, 3.11 |
| Linux/Linuxgeneric | 3.14 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.
Quoted source text, attributed separately from HOL analysis.