* [PATCH] coccinelle: free: add a checker for `__cleanup(kfree)` usage
@ 2026-08-31 13:43 Ella Ma
2026-08-31 15:01 ` [cocci] " Markus Elfring
2026-09-24 16:25 ` [PATCH v2] " Ella Ma
0 siblings, 2 replies; 4+ messages in thread
From: Ella Ma @ 2026-08-31 13:43 UTC (permalink / raw)
To: Julia.Lawall, nicolas.palix; +Cc: alansnape3058, linux-kernel, cocci
Using __cleanup(kfree) will pass the stack address of the annotated
local variable to kfree functions. This will lead to invalid
deallocation issues. Inspired by CVE-2026-45959 and similar bugs
recently detected.
Signed-off-by: Ella Ma <alansnape3058@gmail.com>
---
scripts/coccinelle/free/cleanup-free.cocci | 94 ++++++++++++++++++++++
1 file changed, 94 insertions(+)
create mode 100644 scripts/coccinelle/free/cleanup-free.cocci
diff --git a/scripts/coccinelle/free/cleanup-free.cocci b/scripts/coccinelle/free/cleanup-free.cocci
new file mode 100644
index 000000000000..cdf984ac6b44
--- /dev/null
+++ b/scripts/coccinelle/free/cleanup-free.cocci
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: GPL-2.0-only
+///
+/// Find __cleanup(kfree)
+/// Using __cleanup(kfree) will pass the stack address of the annotated
+/// local variable to kfree, causing an invalid free.
+/// I.e., `T v __cleanup(kfree);` --> `kfree(&v);`
+/// Such usage is impossible to be correct.
+///
+// Confidence: High
+// Copyright: (C) 2026 Ella Ma
+// Options: --no-includes --include-headers
+
+
+// Suggesting using __free for the functions with a DEFINE_FREE definition.
+// Update this list when new DEFINE_FREE definitions are added.
+@free@
+attribute name __cleanup;
+symbol kfree, kfree_sensitive, kvfree, kvfree_atomic;
+type T;
+identifier v, n;
+position p;
+@@
+
+(
+ T v __cleanup@p(
+(
+ n
+&
+(
+ kfree \| kfree_sensitive \| kvfree \| kvfree_atomic
+)
+)
+ );
+|
+ T v __cleanup@p(
+(
+ n
+&
+(
+ kfree \| kfree_sensitive \| kvfree \| kvfree_atomic
+)
+)
+ ) = ...;
+)
+
+@script:python depends on free@
+p << free.p;
+n << free.n;
+@@
+
+coccilib.report.print_report(
+ p[0], f"ERROR: found `__cleanup({n})', do you mean `__free({n})'?")
+
+
+// Reporting __cleanup usage for the functions without a DEFINE_FREE definition.
+// The following list only contains frequently used functions. Supplement it if
+// necessary.
+@cleanup@
+attribute name __cleanup;
+symbol kvfree_sensitive, vfree, vfree_atomic;
+type T;
+identifier v, n;
+position p;
+@@
+
+(
+ T v __cleanup@p(
+(
+ n
+&
+(
+ kvfree_sensitive \| vfree \| vfree_atomic
+)
+)
+ );
+|
+ T v __cleanup@p(
+(
+ n
+&
+(
+ kvfree_sensitive \| vfree \| vfree_atomic
+)
+)
+ ) = ...;
+)
+
+@script:python depends on cleanup@
+p << cleanup.p;
+n << cleanup.n;
+@@
+
+coccilib.report.print_report(
+ p[0], f"ERROR: `__cleanup({n})' will free the annotated variable, rather than its pointee")
--
2.34.1
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [cocci] [PATCH] coccinelle: free: add a checker for `__cleanup(kfree)` usage
2026-08-31 13:43 [PATCH] coccinelle: free: add a checker for `__cleanup(kfree)` usage Ella Ma
@ 2026-08-31 15:01 ` Markus Elfring
2026-09-24 16:25 ` [PATCH v2] " Ella Ma
1 sibling, 0 replies; 4+ messages in thread
From: Markus Elfring @ 2026-08-31 15:01 UTC (permalink / raw)
To: Ella Ma, cocci, Julia Lawall, Nicolas Palix; +Cc: LKML, kernel-janitors
> Using __cleanup(kfree) will pass the stack address of the annotated
> local variable to kfree functions.
I got the impression that this wording approach is improvable.
This attribute probably needs a pointer to an object which was
dynamically allocated.
How do you think about to handle an attribute parameter?
Would you like to support operation modes for coccicheck scripts
in a consistent way?
> This will lead to invalid
> deallocation issues. Inspired by CVE-2026-45959 and similar bugs
> recently detected.
Thanks for such background information.
…
> +++ b/scripts/coccinelle/free/cleanup-free.cocci
> @@ -0,0 +1,94 @@
…
> +/// Find __cleanup(kfree)
> +/// Using __cleanup(kfree) will pass the stack address of the annotated
> +/// local variable to kfree, causing an invalid free.
Would an other wording variant become more helpful?
> +/// I.e., `T v __cleanup(kfree);` --> `kfree(&v);`
> +/// Such usage is impossible to be correct.
…
> +// Suggesting using __free for the functions with a DEFINE_FREE definition.
> +// Update this list when new DEFINE_FREE definitions are added.
> +@free@
> +attribute name __cleanup;
> +symbol kfree, kfree_sensitive, kvfree, kvfree_atomic;
> +type T;
> +identifier v, n;
> +position p;
> +@@
> +
> +(
> + T v __cleanup@p(
> +(
> + n
> +&
> +(
> + kfree \| kfree_sensitive \| kvfree \| kvfree_atomic
> +)
How do you think about to specify relevant function names
on separate lines for such an SmPL conjunction?
Can symbol lists be converted into corresponding case distinctions?
Regards,
Markus
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH v2] coccinelle: free: add a checker for `__cleanup(kfree)` usage
2026-08-31 13:43 [PATCH] coccinelle: free: add a checker for `__cleanup(kfree)` usage Ella Ma
2026-08-31 15:01 ` [cocci] " Markus Elfring
@ 2026-09-24 16:25 ` Ella Ma
2026-09-27 9:43 ` Julia Lawall
1 sibling, 1 reply; 4+ messages in thread
From: Ella Ma @ 2026-09-24 16:25 UTC (permalink / raw)
To: Julia.Lawall, nicolas.palix; +Cc: alansnape3058, linux-kernel, cocci
Using __cleanup(kfree) will pass the stack address of the annotated
local variable to kfree functions. This will lead to invalid
deallocation issues. Inspired by CVE-2026-45959 and similar bugs
recently detected.
Signed-off-by: Ella Ma <alansnape3058@gmail.com>
---
Changes in v2:
- Add virtual rules `report` and `org` as suggested by Sashiko
- Remove `kvfree_sensitive` from rule `cleanup` as suggested by Sashiko
- Add `free_percpu` to rule `free`
- Add `kfree_const` to rule `cleanup`
Currently, the five functions in the `free` rule are all the functions
of `void (*)(const? void *)` type with a `DEFINE_FREE` definition in the
code base. So I adopted all of them.
Function `kfree_const` is added as it is of the kfree family and used
more frequently than other kfree-family functions (even more frequently
than some of those having a `DEFINE_FREE` definition).
https://elixir.bootlin.com/linux/v7.3-rc3/A/ident/kfree_const
(found in 64 files in v7.3-rc3).
This cocci script can report the bug fixed in
https://lore.kernel.org/lkml/20260617142632.3298984-1-vulab@iscas.ac.cn/
scripts/coccinelle/free/cleanup-free.cocci | 112 +++++++++++++++++++++
1 file changed, 112 insertions(+)
create mode 100644 scripts/coccinelle/free/cleanup-free.cocci
diff --git a/scripts/coccinelle/free/cleanup-free.cocci b/scripts/coccinelle/free/cleanup-free.cocci
new file mode 100644
index 000000000000..63216ec5d865
--- /dev/null
+++ b/scripts/coccinelle/free/cleanup-free.cocci
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0-only
+///
+/// Find __cleanup(kfree)
+/// Using __cleanup(kfree) will pass the stack address of the annotated
+/// local variable to kfree, causing an invalid free.
+/// I.e., `T v __cleanup(kfree);` --> `kfree(&v);`
+/// Such usage is impossible to be correct.
+///
+// Confidence: High
+// Copyright: (C) 2026 Ella Ma
+// Options: --no-includes --include-headers
+
+virtual report
+virtual org
+
+// Suggesting using __free for the functions with a DEFINE_FREE definition.
+// Update this list when new DEFINE_FREE definitions are added.
+@free@
+attribute name __cleanup;
+symbol kfree, kfree_sensitive, kvfree, kvfree_atomic, free_percpu;
+type T;
+identifier v, n;
+position p;
+@@
+
+(
+ T v __cleanup@p(
+(
+ n
+&
+(
+ kfree \| kfree_sensitive \| kvfree \| kvfree_atomic \| free_percpu
+)
+)
+ );
+|
+ T v __cleanup@p(
+(
+ n
+&
+(
+ kfree \| kfree_sensitive \| kvfree \| kvfree_atomic \| free_percpu
+)
+)
+ ) = ...;
+)
+
+@script:python depends on report@
+p << free.p;
+n << free.n;
+@@
+
+coccilib.report.print_report(
+ p[0], f"ERROR: found `__cleanup({n})', do you mean `__free({n})'?")
+
+@script:python depends on org@
+p << free.p;
+n << free.n;
+@@
+
+coccilib.org.print_todo(
+ p[0], f"ERROR: found `__cleanup({n})', do you mean `__free({n})'?")
+
+
+// Reporting __cleanup usage for the functions without a DEFINE_FREE definition.
+// The following list only contains frequently used functions. Supplement it if
+// necessary.
+@cleanup@
+attribute name __cleanup;
+symbol vfree, vfree_atomic, kfree_const;
+type T;
+identifier v, n;
+position p;
+@@
+
+(
+ T v __cleanup@p(
+(
+ n
+&
+(
+ vfree \| vfree_atomic \| kfree_const
+)
+)
+ );
+|
+ T v __cleanup@p(
+(
+ n
+&
+(
+ vfree \| vfree_atomic \| kfree_const
+)
+)
+ ) = ...;
+)
+
+@script:python depends on report@
+p << cleanup.p;
+n << cleanup.n;
+@@
+
+coccilib.report.print_report(
+ p[0], f"ERROR: `__cleanup({n})' will free the annotated variable, rather than its pointee")
+
+@script:python depends on org@
+p << cleanup.p;
+n << cleanup.n;
+@@
+
+coccilib.org.print_todo(
+ p[0], f"ERROR: `__cleanup({n})' will free the annotated variable, rather than its pointee")
--
2.34.1
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] coccinelle: free: add a checker for `__cleanup(kfree)` usage
2026-09-24 16:25 ` [PATCH v2] " Ella Ma
@ 2026-09-27 9:43 ` Julia Lawall
0 siblings, 0 replies; 4+ messages in thread
From: Julia Lawall @ 2026-09-27 9:43 UTC (permalink / raw)
To: Ella Ma; +Cc: nicolas.palix, linux-kernel, cocci
On Thu, 24 Sep 2026, Ella Ma wrote:
> Using __cleanup(kfree) will pass the stack address of the annotated
> local variable to kfree functions. This will lead to invalid
> deallocation issues. Inspired by CVE-2026-45959 and similar bugs
> recently detected.
Thanks for the semantic patch.
I think it would be good for the error reports to be more explicit about
what the issue is, ie the relationship to the presence of absence of
DEFINE_FREE. Otherwise, it is hard to completely understand the problem
without looking at the comments in the semantic patch.
julia
>
> Signed-off-by: Ella Ma <alansnape3058@gmail.com>
> ---
>
> Changes in v2:
> - Add virtual rules `report` and `org` as suggested by Sashiko
> - Remove `kvfree_sensitive` from rule `cleanup` as suggested by Sashiko
> - Add `free_percpu` to rule `free`
> - Add `kfree_const` to rule `cleanup`
>
> Currently, the five functions in the `free` rule are all the functions
> of `void (*)(const? void *)` type with a `DEFINE_FREE` definition in the
> code base. So I adopted all of them.
> Function `kfree_const` is added as it is of the kfree family and used
> more frequently than other kfree-family functions (even more frequently
> than some of those having a `DEFINE_FREE` definition).
> https://elixir.bootlin.com/linux/v7.3-rc3/A/ident/kfree_const
> (found in 64 files in v7.3-rc3).
>
> This cocci script can report the bug fixed in
> https://lore.kernel.org/lkml/20260617142632.3298984-1-vulab@iscas.ac.cn/
>
> scripts/coccinelle/free/cleanup-free.cocci | 112 +++++++++++++++++++++
> 1 file changed, 112 insertions(+)
> create mode 100644 scripts/coccinelle/free/cleanup-free.cocci
>
> diff --git a/scripts/coccinelle/free/cleanup-free.cocci b/scripts/coccinelle/free/cleanup-free.cocci
> new file mode 100644
> index 000000000000..63216ec5d865
> --- /dev/null
> +++ b/scripts/coccinelle/free/cleanup-free.cocci
> @@ -0,0 +1,112 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +///
> +/// Find __cleanup(kfree)
> +/// Using __cleanup(kfree) will pass the stack address of the annotated
> +/// local variable to kfree, causing an invalid free.
> +/// I.e., `T v __cleanup(kfree);` --> `kfree(&v);`
> +/// Such usage is impossible to be correct.
> +///
> +// Confidence: High
> +// Copyright: (C) 2026 Ella Ma
> +// Options: --no-includes --include-headers
> +
> +virtual report
> +virtual org
> +
> +// Suggesting using __free for the functions with a DEFINE_FREE definition.
> +// Update this list when new DEFINE_FREE definitions are added.
> +@free@
> +attribute name __cleanup;
> +symbol kfree, kfree_sensitive, kvfree, kvfree_atomic, free_percpu;
> +type T;
> +identifier v, n;
> +position p;
> +@@
> +
> +(
> + T v __cleanup@p(
> +(
> + n
> +&
> +(
> + kfree \| kfree_sensitive \| kvfree \| kvfree_atomic \| free_percpu
> +)
> +)
> + );
> +|
> + T v __cleanup@p(
> +(
> + n
> +&
> +(
> + kfree \| kfree_sensitive \| kvfree \| kvfree_atomic \| free_percpu
> +)
> +)
> + ) = ...;
> +)
> +
> +@script:python depends on report@
> +p << free.p;
> +n << free.n;
> +@@
> +
> +coccilib.report.print_report(
> + p[0], f"ERROR: found `__cleanup({n})', do you mean `__free({n})'?")
> +
> +@script:python depends on org@
> +p << free.p;
> +n << free.n;
> +@@
> +
> +coccilib.org.print_todo(
> + p[0], f"ERROR: found `__cleanup({n})', do you mean `__free({n})'?")
> +
> +
> +// Reporting __cleanup usage for the functions without a DEFINE_FREE definition.
> +// The following list only contains frequently used functions. Supplement it if
> +// necessary.
> +@cleanup@
> +attribute name __cleanup;
> +symbol vfree, vfree_atomic, kfree_const;
> +type T;
> +identifier v, n;
> +position p;
> +@@
> +
> +(
> + T v __cleanup@p(
> +(
> + n
> +&
> +(
> + vfree \| vfree_atomic \| kfree_const
> +)
> +)
> + );
> +|
> + T v __cleanup@p(
> +(
> + n
> +&
> +(
> + vfree \| vfree_atomic \| kfree_const
> +)
> +)
> + ) = ...;
> +)
> +
> +@script:python depends on report@
> +p << cleanup.p;
> +n << cleanup.n;
> +@@
> +
> +coccilib.report.print_report(
> + p[0], f"ERROR: `__cleanup({n})' will free the annotated variable, rather than its pointee")
> +
> +@script:python depends on org@
> +p << cleanup.p;
> +n << cleanup.n;
> +@@
> +
> +coccilib.org.print_todo(
> + p[0], f"ERROR: `__cleanup({n})' will free the annotated variable, rather than its pointee")
> --
> 2.34.1
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-09-27 9:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-08-31 13:43 [PATCH] coccinelle: free: add a checker for `__cleanup(kfree)` usage Ella Ma
2026-08-31 15:01 ` [cocci] " Markus Elfring
2026-09-24 16:25 ` [PATCH v2] " Ella Ma
2026-09-27 9:43 ` Julia Lawall
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®