---
id: CVE-2025-39744
title: 'rcu: Fix rcu_read_unlock() deadloop due to IRQ work'
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  rcu: Fix rcu_read_unlock() deadloop due to IRQ work

  During rcu_read_unlock_special(), if this happens during irq_exit(), we
  can lockup if an IPI is issued. This is bec…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 0864f057b050bc6dd68106b3185e02db5140012d <
    6b552ffd21f9be57806ade167a757f32dd66a98d
  - >-
    Linux >= 0864f057b050bc6dd68106b3185e02db5140012d <
    e7a375453cca2b8a0d2fa1b82b913f3fed7c0507
  - >-
    Linux >= 0864f057b050bc6dd68106b3185e02db5140012d <
    1cfa244f7198d325594e627574930b7b91df5bfe
  - >-
    Linux >= 0864f057b050bc6dd68106b3185e02db5140012d <
    ddebb2a7677673cf4438a04e1a48b8ed6b0c8e9a
  - >-
    Linux >= 0864f057b050bc6dd68106b3185e02db5140012d <
    56c5ef194f4509df63fc0f7a91ea5973ce479b1e
  - >-
    Linux >= 0864f057b050bc6dd68106b3185e02db5140012d <
    b41642c87716bbd09797b1e4ea7d904f06c39b7b
  - Linux 5.3
published: '2025-09-11'
updated: '2026-10-30'
sourceUpdated: '2026-10-30T12:22:24.618Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2025-39744'
references:
  - url: 'https://git.kernel.org/stable/c/6b552ffd21f9be57806ade167a757f32dd66a98d'
  - url: 'https://git.kernel.org/stable/c/e7a375453cca2b8a0d2fa1b82b913f3fed7c0507'
  - url: 'https://git.kernel.org/stable/c/1cfa244f7198d325594e627574930b7b91df5bfe'
  - url: 'https://git.kernel.org/stable/c/ddebb2a7677673cf4438a04e1a48b8ed6b0c8e9a'
  - url: 'https://git.kernel.org/stable/c/56c5ef194f4509df63fc0f7a91ea5973ce479b1e'
  - url: 'https://git.kernel.org/stable/c/b41642c87716bbd09797b1e4ea7d904f06c39b7b'
tags:
  - cve.org
epss: 0.00164
epssPercentile: 0.05613
ingestedAt: '2026-11-03T20:54:32.504Z'
---

## Overview

In the Linux kernel, the following vulnerability has been resolved:

rcu: Fix rcu_read_unlock() deadloop due to IRQ work

During rcu_read_unlock_special(), if this happens during irq_exit(), we
can lockup if an IPI is issued. This is because the IPI itself triggers
the irq_exit() path causing a recursive lock up.

This is precisely what Xiongfeng found when invoking a BPF program on
the trace_tick_stop() tracepoint As shown in the trace below. Fix by
managing the irq_work state correctly.

irq_exit()
  __irq_exit_rcu()
    /* in_hardirq() returns false after this */
    preempt_count_sub(HARDIRQ_OFFSET)
    tick_irq_exit()
      tick_nohz_irq_exit()
	    tick_nohz_stop_sched_tick()
	      trace_tick_stop()  /* a bpf prog is hooked on this trace point */
		   __bpf_trace_tick_stop()
		      bpf_trace_run2()
			    rcu_read_unlock_special()
                              /* will send a IPI to itself */
			      irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);

A simple reproducer can also be obtained by doing the following in
tick_irq_exit(). It will hang on boot without the patch:

  static inline void tick_irq_exit(void)
  {
 +	rcu_read_lock();
 +	WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true);
 +	rcu_read_unlock();
 +

[neeraj: Apply Frederic's suggested fix for PREEMPT_RT]

## Affected

- `Linux >= 0864f057b050bc6dd68106b3185e02db5140012d < 6b552ffd21f9be57806ade167a757f32dd66a98d`
- `Linux >= 0864f057b050bc6dd68106b3185e02db5140012d < e7a375453cca2b8a0d2fa1b82b913f3fed7c0507`
- `Linux >= 0864f057b050bc6dd68106b3185e02db5140012d < 1cfa244f7198d325594e627574930b7b91df5bfe`
- `Linux >= 0864f057b050bc6dd68106b3185e02db5140012d < ddebb2a7677673cf4438a04e1a48b8ed6b0c8e9a`
- `Linux >= 0864f057b050bc6dd68106b3185e02db5140012d < 56c5ef194f4509df63fc0f7a91ea5973ce479b1e`
- `Linux >= 0864f057b050bc6dd68106b3185e02db5140012d < b41642c87716bbd09797b1e4ea7d904f06c39b7b`
- `Linux 5.3`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.