In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Add validation for lmac type Upon physical link change, firmware reports to the kernel about the change along with the details like speed, lmac_type_id, etc. Kernel derives lmac_type based on lmac_type_id received from firmware. In a few scenarios, firmware returns an invalid lmac_type_id, which is resulting in below kernel panic. This patch adds the missing validation of the lmac_type_id field. Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 35.321595] Modules linked in: [ 35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.4.210-g2e3169d8e1bc-dirty #17 [ 35.337014] Hardware name: Marvell CN103XX board (DT) [ 35.344297] Workqueue: events work_for_cpu_fn [ 35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO) [ 35.360267] pc : strncpy+0x10/0x30 [ 35.366595] lr : cgx_link_change_handler+0x90/0x180

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1786761805 advisory.

  - A flaw was found in the KVM's AMD nested virtualization (SVM). A malicious L1 guest could purposely fail     to intercept the shutdown of a cooperative nested guest (L2), possibly leading to a page fault and kernel     panic in the host (L0). (CVE-2022-3344)

  - In the Linux kernel, the following vulnerability has been resolved: usbnet: Run unregister_netdev() before     unbind() again Commit 2c9d6c2b871d (usbnet: run unbind() before unregister_netdev()) sought to fix a     use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to     address the issue:
    https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So     the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before,     usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect()     mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in     usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY     disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it     closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may     only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to     phy_stop() unconditional in ->stop(). (CVE-2022-49501)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: arm64/poly1305 - fix a read     out-of-bound A kasan error was reported during fuzzing: BUG: KASAN: slab-out-of-bounds in     neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] Read of size 4 at addr ffff0010e293f010 by     task syz-executor.5/1646715 CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted     5.10.0.aarch64 #1 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019 Call trace:
    dump_backtrace+0x0/0x394 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196 __dump_stack     lib/dump_stack.c:77 [inline] dump_stack+0x158/0x1e4 lib/dump_stack.c:118     print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387 __kasan_report+0xe0/0x140     mm/kasan/report.c:547 kasan_report+0x44/0xe0 mm/kasan/report.c:564 check_memory_region_inline     mm/kasan/generic.c:187 [inline] __asan_load4+0x94/0xd0 mm/kasan/generic.c:252     neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon] neon_poly1305_do_update+0x6c/0x15c     [poly1305_neon] neon_poly1305_update+0x9c/0x1c4 [poly1305_neon] crypto_shash_update crypto/shash.c:131     [inline] shash_finup_unaligned+0x84/0x15c crypto/shash.c:179 crypto_shash_finup+0x8c/0x140     crypto/shash.c:193 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201 crypto_shash_digest+0xa4/0xfc     crypto/shash.c:217 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229 essiv_skcipher_setkey+0x164/0x200     [essiv] crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612 skcipher_setkey+0x3c/0x50     crypto/algif_skcipher.c:305 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220 alg_setsockopt+0x19c/0x210     crypto/af_alg.c:253 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123 __do_sys_setsockopt net/socket.c:2134     [inline] __se_sys_setsockopt net/socket.c:2131 [inline] __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
    __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline] invoke_syscall+0x64/0x100     arch/arm64/kernel/syscall.c:48 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155     do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217 el0_svc+0x24/0x3c arch/arm64/kernel/entry-     common.c:353 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369 el0_sync+0x160/0x180     arch/arm64/kernel/entry.S:683 This error can be reproduced by the following code compiled as ko on a     system with kasan enabled: #include <linux/module.h> #include <linux/crypto.h> #include <crypto/hash.h>     #include <crypto/poly1305.h> char test_data[] = \x00\x01\x02\x03\x04\x05\x06\x07     \x08\x09\x0a\x0b\x0c\x0d\x0e\x0f \x10\x11\x12\x13\x14\x15\x16\x17 \x18\x19\x1a\x1b\x1c\x1d\x1e; int     init(void) { struct crypto_shash *tfm = NULL; char *data = NULL, *out = NULL; tfm =     crypto_alloc_shash(poly1305, 0, 0); data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL); out =     kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL); memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
    crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out); kfree(data); kfree(out); return 0; } void     deinit(void) { } module_init(init) module_exit(deinit) MODULE_LICENSE(GPL); The root cause of the bug     sits in neon_poly1305_blocks. The logic neon_poly1305_blocks() performed is that if it was called with     both s[] and r[] uninitialized, it will first try to initialize them with the data from the first block     that it believed to be 32 bytes in length. First 16 bytes are used as the key and the next 16 bytes for     s[]. This would lead to the aforementioned read out-of-bound. However, after calling poly1305_init_arch(),     only 16 bytes were deducted from the input and s[] is initialized yet again with the following 16 bytes.
    The second initialization of s[] is certainly redundent which indicates that the first initialization     should be for r[] only. This patch fixes the issue by calling poly1305_init_arm64() instead o
    ---truncated--- (CVE-2022-50231)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix reference state management     for synchronous callbacks Currently, verifier verifies callback functions (sync and async) as if they will     be executed once, (i.e. it explores execution state as if the function was being called once). The next     insn to explore is set to start of subprog and the exit from nested frame is handled using curframe > 0     and prepare_func_exit. In case of async callback it uses a customized variant of push_stack simulating a     kind of branch to set up custom state and execution context for the async callback. While this approach is     simple and works when callback really will be executed only once, it is unsafe for all of our current     helpers which are for_each style, i.e. they execute the callback multiple times. A callback releasing     acquired references of the caller may do so multiple times, but currently verifier sees it as one call     inside the frame, which then returns to caller. Hence, it thinks it released some reference that the cb     e.g. got access through callback_ctx (register filled inside cb from spilled typed register on stack).
    Similarly, it may see that an acquire call is unpaired inside the callback, so the caller will copy the     reference state of callback and then will have to release the register with new ref_obj_ids. But again,     the callback may execute multiple times, but the verifier will only account for acquired references for a     single symbolic execution of the callback, which will cause leaks. Note that for async callback case,     things are different. While currently we have bpf_timer_set_callback which only executes it once, even for     multiple executions it would be safe, as reference state is NULL and check_reference_leak would force     program to release state before BPF_EXIT. The state is also unaffected by analysis for the caller frame.
    Hence async callback is safe. Since we want the reference state to be accessible, e.g. for pointers loaded     from stack through callback_ctx's PTR_TO_STACK, we still have to copy caller's reference_state to     callback's bpf_func_state, but we enforce that whatever references it adds to that reference_state has     been released before it hits BPF_EXIT. This requires introducing a new callback_ref member in the     reference state to distinguish between caller vs callee references. Hence, check_reference_leak now errors     out if it sees we are in callback_fn and we have not released callback_ref refs. Since there can be     multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc. we need to also distinguish between whether     this particular ref belongs to this callback frame or parent, and only error for our own, so we store     state->frameno (which is always non-zero for callbacks). In short, callbacks can read parent     reference_state, but cannot mutate it, to be able to use pointers acquired by the caller. They must only     undo their changes (by releasing their own acquired_refs before BPF_EXIT) on top of caller reference_state     before returning (at which point the caller and callback state will match anyway, so no need to copy it     back to caller). (CVE-2022-50650)

  - In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix possible memory leak     in stmmac_dvr_probe() The bitmap_free() should be called to free priv->af_xdp_zc_qps when     create_singlethread_workqueue() fails, otherwise there will be a memory leak, so we add the err path     error_wq_init to fix it. (CVE-2022-50663)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

An update of the linux package has been released.

The remote Debian 11 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4664 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4664-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     July 03, 2026                                 https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux     Version        : 5.10.259-1     CVE ID         : CVE-2021-47188 CVE-2021-47211 CVE-2022-48703 CVE-2022-49135                      CVE-2022-49158 CVE-2022-49183 CVE-2022-49822 CVE-2022-50073                      CVE-2022-50472 CVE-2022-50493 CVE-2022-50552 CVE-2023-53133                      CVE-2023-53421 CVE-2023-53596 CVE-2023-54129 CVE-2024-43902                      CVE-2025-10263 CVE-2025-21863 CVE-2025-22026 CVE-2025-22107                      CVE-2025-38129 CVE-2025-38250 CVE-2025-38584 CVE-2025-38710                      CVE-2025-39929 CVE-2025-40164 CVE-2025-68340 CVE-2026-23066                      CVE-2026-23099 CVE-2026-23442 CVE-2026-23444 CVE-2026-31407                      CVE-2026-31449 CVE-2026-31489 CVE-2026-31532 CVE-2026-31576                      CVE-2026-31577 CVE-2026-31578 CVE-2026-31580 CVE-2026-31581                      CVE-2026-31583 CVE-2026-31585 CVE-2026-31586 CVE-2026-31588                      CVE-2026-31590 CVE-2026-31596 CVE-2026-31597 CVE-2026-31598                      CVE-2026-31599 CVE-2026-31602 CVE-2026-31603 CVE-2026-31605                      CVE-2026-31607 CVE-2026-31615 CVE-2026-31616 CVE-2026-31617                      CVE-2026-31618 CVE-2026-31619 CVE-2026-31622 CVE-2026-31623                      CVE-2026-31624 CVE-2026-31625 CVE-2026-31626 CVE-2026-31627                      CVE-2026-31629 CVE-2026-31630 CVE-2026-31634 CVE-2026-31637                      CVE-2026-31642 CVE-2026-31656 CVE-2026-31657 CVE-2026-31664                      CVE-2026-31673 CVE-2026-31676 CVE-2026-31681 CVE-2026-31684                      CVE-2026-31685 CVE-2026-31686 CVE-2026-31696 CVE-2026-31697                      CVE-2026-31698 CVE-2026-31699 CVE-2026-31700 CVE-2026-31701                      CVE-2026-31708 CVE-2026-31715 CVE-2026-43052 CVE-2026-43058                      CVE-2026-43075 CVE-2026-43076 CVE-2026-43080 CVE-2026-43085                      CVE-2026-43089 CVE-2026-43093 CVE-2026-43103 CVE-2026-43104                      CVE-2026-43105 CVE-2026-43110 CVE-2026-43111 CVE-2026-43113                      CVE-2026-43114 CVE-2026-43117 CVE-2026-43281 CVE-2026-43350                      CVE-2026-43492 CVE-2026-43493 CVE-2026-43494 CVE-2026-43496                      CVE-2026-43497 CVE-2026-43501 CVE-2026-43502 CVE-2026-45834                      CVE-2026-45835 CVE-2026-45836 CVE-2026-45838 CVE-2026-45840                      CVE-2026-45841 CVE-2026-45842 CVE-2026-45843 CVE-2026-45844                      CVE-2026-45846 CVE-2026-45850 CVE-2026-45986 CVE-2026-45987                      CVE-2026-45991 CVE-2026-45994 CVE-2026-46002 CVE-2026-46003                      CVE-2026-46004 CVE-2026-46006 CVE-2026-46018 CVE-2026-46019                      CVE-2026-46021 CVE-2026-46022 CVE-2026-46023 CVE-2026-46026                      CVE-2026-46027 CVE-2026-46033 CVE-2026-46038 CVE-2026-46040                      CVE-2026-46043 CVE-2026-46044 CVE-2026-46046 CVE-2026-46047                      CVE-2026-46049 CVE-2026-46051 CVE-2026-46052 CVE-2026-46053                      CVE-2026-46056 CVE-2026-46064 CVE-2026-46069 CVE-2026-46070                      CVE-2026-46077 CVE-2026-46078 CVE-2026-46080 CVE-2026-46086                      CVE-2026-46088 CVE-2026-46090 CVE-2026-46091 CVE-2026-46098                      CVE-2026-46101 CVE-2026-46102 CVE-2026-46103 CVE-2026-46107                      CVE-2026-46108 CVE-2026-46109 CVE-2026-46120 CVE-2026-46122                      CVE-2026-46124 CVE-2026-46127 CVE-2026-46128 CVE-2026-46132                      CVE-2026-46133 CVE-2026-46137 CVE-2026-46146 CVE-2026-46149                      CVE-2026-46150 CVE-2026-46151 CVE-2026-46159 CVE-2026-46160                      CVE-2026-46161 CVE-2026-46163 CVE-2026-46167 CVE-2026-46169                      CVE-2026-46172 CVE-2026-46177 CVE-2026-46178 CVE-2026-46180                      CVE-2026-46184 CVE-2026-46187 CVE-2026-46189 CVE-2026-46191                      CVE-2026-46196 CVE-2026-46198 CVE-2026-46205 CVE-2026-46206                      CVE-2026-46208 CVE-2026-46209 CVE-2026-46212 CVE-2026-46214                      CVE-2026-46220 CVE-2026-46227 CVE-2026-46231 CVE-2026-46233                      CVE-2026-46234 CVE-2026-46236 CVE-2026-46238 CVE-2026-46275                      CVE-2026-46276 CVE-2026-46285 CVE-2026-46291 CVE-2026-46292                      CVE-2026-46294 CVE-2026-46299 CVE-2026-46301 CVE-2026-46303                      CVE-2026-46304 CVE-2026-46307 CVE-2026-46319 CVE-2026-46320                      CVE-2026-46321 CVE-2026-46322 CVE-2026-52909 CVE-2026-52910                      CVE-2026-52912 CVE-2026-52913 CVE-2026-52914 CVE-2026-52915                      CVE-2026-52916 CVE-2026-52917 CVE-2026-52918 CVE-2026-52919                      CVE-2026-52920 CVE-2026-52921 CVE-2026-52922 CVE-2026-52923                      CVE-2026-52924 CVE-2026-52925 CVE-2026-52926 CVE-2026-52927                      CVE-2026-52929 CVE-2026-52930 CVE-2026-52931 CVE-2026-52934                      CVE-2026-52935 CVE-2026-52939 CVE-2026-52943 CVE-2026-52946                      CVE-2026-52947 CVE-2026-52948 CVE-2026-52954 CVE-2026-52955                      CVE-2026-52957 CVE-2026-52958 CVE-2026-52962 CVE-2026-52963                      CVE-2026-52970 CVE-2026-52972 CVE-2026-52982 CVE-2026-52984                      CVE-2026-52985 CVE-2026-52986 CVE-2026-52992 CVE-2026-52993                      CVE-2026-52995 CVE-2026-52998 CVE-2026-52999 CVE-2026-53001                      CVE-2026-53002 CVE-2026-53003 CVE-2026-53004 CVE-2026-53006                      CVE-2026-53011 CVE-2026-53012 CVE-2026-53016 CVE-2026-53021                      CVE-2026-53037 CVE-2026-53039 CVE-2026-53040 CVE-2026-53041                      CVE-2026-53043 CVE-2026-53045 CVE-2026-53047 CVE-2026-53050                      CVE-2026-53059 CVE-2026-53060 CVE-2026-53061 CVE-2026-53062                      CVE-2026-53064 CVE-2026-53065 CVE-2026-53068 CVE-2026-53071                      CVE-2026-53072 CVE-2026-53073 CVE-2026-53074 CVE-2026-53075                      CVE-2026-53077 CVE-2026-53080 CVE-2026-53082 CVE-2026-53088                      CVE-2026-53093 CVE-2026-53112 CVE-2026-53128 CVE-2026-53130                      CVE-2026-53133 CVE-2026-53134 CVE-2026-53135 CVE-2026-53137                      CVE-2026-53146 CVE-2026-53148 CVE-2026-53149 CVE-2026-53150                      CVE-2026-53161 CVE-2026-53168 CVE-2026-53176 CVE-2026-53181                      CVE-2026-53186 CVE-2026-53189 CVE-2026-53194 CVE-2026-53195                      CVE-2026-53196 CVE-2026-53199 CVE-2026-53208 CVE-2026-53212                      CVE-2026-53217 CVE-2026-53218 CVE-2026-53219 CVE-2026-53221                      CVE-2026-53223 CVE-2026-53225 CVE-2026-53227 CVE-2026-53228                      CVE-2026-53238 CVE-2026-53239 CVE-2026-53242 CVE-2026-53245                      CVE-2026-53249 CVE-2026-53255 CVE-2026-53256 CVE-2026-53263                      CVE-2026-53264 CVE-2026-53266 CVE-2026-53268 CVE-2026-53269                      CVE-2026-53270 CVE-2026-53273 CVE-2026-53287 CVE-2026-53294                      CVE-2026-53295 CVE-2026-53296 CVE-2026-53304 CVE-2026-53309                      CVE-2026-53320 CVE-2026-53337 CVE-2026-53339 CVE-2026-53352                      CVE-2026-53354 CVE-2026-53355 CVE-2026-53356 CVE-2026-53357     Debian Bug     : 1130365 1119093

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For Debian 11 bullseye, these problems have been fixed in version     5.10.259-1.  This version additionally includes many more bug fixes     from stable updates 5.10.258 and 5.10.259.

    We recommend that you upgrade your linux packages.

    For the detailed security status of linux please refer to     its security tracker page at:
    https://security-tracker.debian.org/tracker/linux

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - octeontx2-af: Add validation for lmac type Upon physical link change, firmware reports to the kernel about     the change along with the details like speed, lmac_type_id, etc. Kernel derives lmac_type based on     lmac_type_id received from firmware. In a few scenarios, firmware returns an invalid lmac_type_id, which     is resulting in below kernel panic. This patch adds the missing validation of the lmac_type_id field.
    Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 35.321595] Modules linked in: [ 35.328982] CPU: 0 PID:
    31 Comm: kworker/0:1 Not tainted 5.4.210-g2e3169d8e1bc-dirty #17 [ 35.337014] Hardware name: Marvell     CN103XX board (DT) [ 35.344297] Workqueue: events work_for_cpu_fn [ 35.352730] pstate: 40400089 (nZcv daIf     +PAN -UAO) [ 35.360267] pc : strncpy+0x10/0x30 [ 35.366595] lr : cgx_link_change_handler+0x90/0x180     (CVE-2023-54129)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
352031	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1786761805)	Nessus	Alma Linux Local Security Checks	Local	critical
326306	Photon OS 4.0: Linux PHSA-2026-4.0-1054	Nessus	PhotonOS Local Security Checks	Local	high
325018	Debian dla-4664 : ata-modules-5.10.0-43-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
279849	Linux Distros Unpatched Vulnerability : CVE-2023-54129	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2023-54129

high

Tenable Plugins

critical

high

high

high