Missing Release of Resource after Effective Lifetime Affecting kernel-livepatch-6.12.103-127.188 package, versions <1:1.0-0.amzn2023


Severity

Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.18% (8th 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-AMZN2023-KERNELLIVEPATCH612103127188-19473754
  • published1 Sept 2026
  • disclosed15 Aug 2026

Introduced: 15 Aug 2026

NewCVE-2026-72116  (opens in a new tab)
CWE-772  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 kernel-livepatch-6.12.103-127.188 to version 1:1.0-0.amzn2023 or higher.
This issue was patched in ALAS2023-2026-2110.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-6.12.103-127.188 package and not the kernel-livepatch-6.12.103-127.188 package as distributed by Amazon-Linux. See How to fix? for Amazon-Linux:2023 relevant fixed versions and status.

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

can: bcm: fix stale rx/tx ops after device removal

RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is.

TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it.

Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.

CVSS Base Scores

version 3.1