lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <fafea50899e36d26ea6900b7187bf994795f96db8b6de497c8bb12bdcca71521@mail.kernel.org>
Date: Thu,  5 Feb 2026 07:37:48 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: ameryhung@...il.com,bpf@...r.kernel.org
Cc: netdev@...r.kernel.org,alexei.starovoitov@...il.com,andrii@...nel.org,daniel@...earbox.net,memxor@...il.com,martin.lau@...nel.org,kpsingh@...nel.org,yonghong.song@...ux.dev,song@...nel.org,haoluo@...gle.com,ameryhung@...il.com,kernel-team@...a.com,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,clm@...a.com,ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next v6 05/17] bpf: Change local_storage->lock and b->lock to rqspinlock

> diff --git a/kernel/bpf/bpf_local_storage.c b/kernel/bpf/bpf_local_storage.c
> index 5dcdf8e52..b33ef5fb5 100644
> --- a/kernel/bpf/bpf_local_storage.c
> +++ b/kernel/bpf/bpf_local_storage.c

[ ... ]

> @@ -700,7 +724,7 @@ void bpf_local_storage_destroy(struct bpf_local_storage *local_storage)
>  	 * when unlinking elem from the local_storage->list and
>  	 * the map's bucket->list.
>  	 */
> -	raw_spin_lock_irqsave(&local_storage->lock, flags);
> +	raw_res_spin_lock_irqsave(&local_storage->lock, flags);

The commit message says the return value is ignored here "for now", with a
later patch allowing unlinking even when failing to acquire locks.

However, if raw_res_spin_lock_irqsave() fails (returning -EDEADLK or
-ETIMEDOUT), the code continues and then calls
raw_res_spin_unlock_irqrestore() at the end of the function:

> @@ -715,7 +739,7 @@ void bpf_local_storage_destroy(struct bpf_local_storage *local_storage)
>  		free_storage = bpf_selem_unlink_storage_nolock(
>  			local_storage, selem, &free_selem_list);
>  	}
> -	raw_spin_unlock_irqrestore(&local_storage->lock, flags);
> +	raw_res_spin_unlock_irqrestore(&local_storage->lock, flags);

When raw_res_spin_lock_irqsave() fails, it decrements the per-CPU
rqspinlock_held_locks.cnt in release_held_lock_entry(). Later,
raw_res_spin_unlock_irqrestore() calls res_spin_unlock() which:

1. Writes 0 to lock->locked via smp_store_release(), potentially corrupting
   a lock held by another CPU
2. Decrements rqspinlock_held_locks.cnt again, causing an underflow
3. Calls preempt_enable() without a matching preempt_disable()

This is fixed by commit 6327eea8e ("bpf: Switch to bpf_selem_unlink_nofail
in bpf_local_storage_{map_free, destroy}") which rewrites this function to
use bpf_selem_unlink_nofail() that properly handles lock failures.

Should the unlock be made conditional on successful lock acquisition in
this patch, or is the brief window of potential corruption considered
acceptable given the fix follows shortly in the series?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21702523104

AI-authorship-score: low
AI-authorship-explanation: The commit follows standard kernel conventions with appropriate technical detail and no signs of AI-generated content; the changes are mechanical type conversions consistent with human-authored kernel patches.
issues-found: 1
issue-severity-score: medium
issue-severity-explanation: Lock imbalance in bpf_local_storage_destroy() can cause per-CPU counter underflow and lock corruption if rqspinlock acquisition fails, though the issue is fixed in a later commit in the same series.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ