CVE-2024-56655 Affecting kernel-abi-whitelists package, versions *


Severity

Recommended
low

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.05% (18th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL7-KERNELABIWHITELISTS-8553010
  • published28 Dec 2024
  • disclosed27 Dec 2024

Introduced: 27 Dec 2024

NewCVE-2024-56655  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:7 kernel-abi-whitelists.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-abi-whitelists package and not the kernel-abi-whitelists package as distributed by RHEL. See How to fix? for RHEL:7 relevant fixed versions and status.

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

netfilter: nf_tables: do not defer rule destruction via call_rcu

nf_tables_chain_destroy can sleep, it can't be used from call_rcu callbacks.

Moreover, nf_tables_rule_release() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronize_rcu() in-between.

nft_rule_expr_deactivate() callbacks will change ->use counters of other chains/sets, see e.g. nft_lookup .deactivate callback, these must be serialized via transaction mutex.

Also add a few lockdep asserts to make this more explicit.

Calling synchronize_rcu() isn't ideal, but fixing this without is hard and way more intrusive. As-is, we can get:

WARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x.. Workqueue: events nf_tables_trans_destroy_work RIP: 0010:nft_set_destroy+0x3fe/0x5c0 Call Trace: <TASK> nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0

In case the synchronize_rcu becomes an issue, we can explore alternatives.

One way would be to allocate nft_trans_rule objects + one nft_trans_chain object, deactivate the rules + the chain and then defer the freeing to the nft destroy workqueue. We'd still need to keep the synchronize_rcu path as a fallback to handle -ENOMEM corner cases though.

CVSS Scores

version 3.1