In the Linux kernel, the following vulnerability has been resolved: bpf: Track subprog poke descriptors correctly and fix use-after-free Subprograms are calling map_poke_track(), but on program release there is no hook to call map_poke_untrack(). However, on program release, the aux memory (and poke descriptor table) is freed even though we still have a reference to it in the element list of the map aux data. When we run map_poke_run(), we then end up accessing free'd memory, triggering KASAN in prog_array_map_poke_run(): [...] [ 402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337 [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399 [ 402.824715] Call Trace: [ 402.824719] dump_stack+0x93/0xc2 [ 402.824727] print_address_description.constprop.0+0x1a/0x140 [ 402.824736] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824744] kasan_report.cold+0x7c/0xd8 [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824757] prog_array_map_poke_run+0xc2/0x34e [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0 [...] The elements concerned are walked as follows: for (i = 0; i < elem->aux->size_poke_tab; i++) { poke = &elem->aux->poke_tab[i]; [...] The access to size_poke_tab is a 4 byte read, verified by checking offsets in the KASAN dump: [ 402.825004] The buggy address belongs to the object at ffff8881905a7800 which belongs to the cache kmalloc-1k of size 1024 [ 402.825008] The buggy address is located 320 bytes inside of 1024-byte region [ffff8881905a7800, ffff8881905a7c00) The pahole output of bpf_prog_aux: struct bpf_prog_aux { [...] /* --- cacheline 5 boundary (320 bytes) --- */ u32 size_poke_tab; /* 320 4 */ [...] In general, subprograms do not necessarily manage their own data structures. For example, BTF func_info and linfo are just pointers to the main program structure. This allows reference counting and cleanup to be done on the latter which simplifies their management a bit. The aux->poke_tab struct, however, did not follow this logic. The initial proposed fix for this use-after-free bug further embedded poke data tracking into the subprogram with proper reference counting. However, Daniel and Alexei questioned why we were treating these objects special; I agree, its unnecessary. The fix here removes the per subprogram poke table allocation and map tracking and instead simply points the aux->poke_tab pointer at the main programs poke table. This way, map tracking is simplified to the main program and we do not need to manage them per subprogram. This also means, bpf_prog_free_deferred(), which unwinds the program reference counting and kfrees objects, needs to ensure that we don't try to double free the poke_tab when free'ing the subprog structures. This is easily solved by NULL'ing the poke_tab pointer. The second detail is to ensure that per subprogram JIT logic only does fixups on poke_tab[] entries it owns. To do this, we add a pointer in the poke structure to point at the subprogram value so JITs can easily check while walking the poke_tab structure if the current entry belongs to the current program. The aux pointer is stable and therefore suitable for such comparison. On the jit_subprogs() error path, we omit cleaning up the poke->aux field because these are only ever referenced from the JIT side, but on error we will never make it to the JIT, so its fine to leave them dangling. Removing these pointers would complicate the error path for no reason. However, we do need to untrack all poke descriptors from the main program as otherwise they could race with the freeing of JIT memory from the subprograms. Lastly, a748c6975dea3 ("bpf: propagate poke des ---truncated---

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-986996 advisory.

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

    bpf: Track subprog poke descriptors correctly and fix use-after-free

    Subprograms are calling map_poke_track(), but on program release there is no     hook to call map_poke_untrack(). However, on program release, the aux memory     (and poke descriptor table) is freed even though we still have a reference to     it in the element list of the map aux data. When we run map_poke_run(), we then     end up accessing free'd memory, triggering KASAN in prog_array_map_poke_run():

      [...]       [  402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e       [  402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337       [  402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G          I       5.12.0+ #399       [  402.824715] Call Trace:
      [  402.824719]  dump_stack+0x93/0xc2       [  402.824727]  print_address_description.constprop.0+0x1a/0x140       [  402.824736]  ? prog_array_map_poke_run+0xc2/0x34e       [  402.824740]  ? prog_array_map_poke_run+0xc2/0x34e       [  402.824744]  kasan_report.cold+0x7c/0xd8       [  402.824752]  ? prog_array_map_poke_run+0xc2/0x34e       [  402.824757]  prog_array_map_poke_run+0xc2/0x34e       [  402.824765]  bpf_fd_array_map_update_elem+0x124/0x1a0       [...]

    The elements concerned are walked as follows:

        for (i = 0; i < elem->aux->size_poke_tab; i++) {                poke = &elem->aux->poke_tab[i];
        [...]

    The access to size_poke_tab is a 4 byte read, verified by checking offsets     in the KASAN dump:

      [  402.825004] The buggy address belongs to the object at ffff8881905a7800                      which belongs to the cache kmalloc-1k of size 1024       [  402.825008] The buggy address is located 320 bytes inside of                      1024-byte region [ffff8881905a7800, ffff8881905a7c00)

    The pahole output of bpf_prog_aux:

      struct bpf_prog_aux {         [...]         /* --- cacheline 5 boundary (320 bytes) --- */         u32                        size_poke_tab;        /*   320     4 */         [...]

    In general, subprograms do not necessarily manage their own data structures.
    For example, BTF func_info and linfo are just pointers to the main program     structure. This allows reference counting and cleanup to be done on the latter     which simplifies their management a bit. The aux->poke_tab struct, however,     did not follow this logic. The initial proposed fix for this use-after-free     bug further embedded poke data tracking into the subprogram with proper     reference counting. However, Daniel and Alexei questioned why we were treating     these objects special; I agree, its unnecessary. The fix here removes the per     subprogram poke table allocation and map tracking and instead simply points     the aux->poke_tab pointer at the main programs poke table. This way, map     tracking is simplified to the main program and we do not need to manage them     per subprogram.

    This also means, bpf_prog_free_deferred(), which unwinds the program reference     counting and kfrees objects, needs to ensure that we don't try to double free     the poke_tab when free'ing the subprog structures. This is easily solved by     NULL'ing the poke_tab pointer. The second detail is to ensure that per     subprogram JIT logic only does fixups on poke_tab[] entries it owns. To do     this, we add a pointer in the poke structure to point at the subprogram value     so JITs can easily check while walking the poke_tab structure if the current     entry belongs to the current program. The aux pointer is stable and therefore     suitable for such comparison. On the jit_subprogs() error path, we omit     cleaning up the poke->aux field because these are only ever referenced from     the JIT side, but on error we will never make it to the JIT, so its fine to     leave them dangling. Removing these pointers would complicate the error path     for no reason. However, we do need to untrack all poke descriptors from the     main program as otherwise they could race with the freeing of JIT memory from     the subprograms. Lastly, a748c6975dea3 (bpf: propagate poke des
    ---truncated---

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

Note that Nessus has not tested for this issue 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.

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Track subprog poke descriptors     correctly and fix use-after-free Subprograms are calling map_poke_track(), but on program release there is     no hook to call map_poke_untrack(). However, on program release, the aux memory (and poke descriptor     table) is freed even though we still have a reference to it in the element list of the map aux data. When     we run map_poke_run(), we then end up accessing free'd memory, triggering KASAN in     prog_array_map_poke_run(): [...] [ 402.824689] BUG: KASAN: use-after-free in     prog_array_map_poke_run+0xc2/0x34e [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-     fgs/4337 [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399 [ 402.824715] Call     Trace: [ 402.824719] dump_stack+0x93/0xc2 [ 402.824727] print_address_description.constprop.0+0x1a/0x140 [     402.824736] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e [     402.824744] kasan_report.cold+0x7c/0xd8 [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824757]     prog_array_map_poke_run+0xc2/0x34e [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0 [...] The     elements concerned are walked as follows: for (i = 0; i < elem->aux->size_poke_tab; i++) { poke =     &elem->aux->poke_tab[i]; [...] The access to size_poke_tab is a 4 byte read, verified by checking offsets     in the KASAN dump: [ 402.825004] The buggy address belongs to the object at ffff8881905a7800 which belongs     to the cache kmalloc-1k of size 1024 [ 402.825008] The buggy address is located 320 bytes inside of     1024-byte region [ffff8881905a7800, ffff8881905a7c00) The pahole output of bpf_prog_aux: struct     bpf_prog_aux { [...] /* --- cacheline 5 boundary (320 bytes) --- */ u32 size_poke_tab; /* 320 4 */ [...]     In general, subprograms do not necessarily manage their own data structures. For example, BTF func_info     and linfo are just pointers to the main program structure. This allows reference counting and cleanup to     be done on the latter which simplifies their management a bit. The aux->poke_tab struct, however, did not     follow this logic. The initial proposed fix for this use-after-free bug further embedded poke data     tracking into the subprogram with proper reference counting. However, Daniel and Alexei questioned why we     were treating these objects special; I agree, its unnecessary. The fix here removes the per subprogram     poke table allocation and map tracking and instead simply points the aux->poke_tab pointer at the main     programs poke table. This way, map tracking is simplified to the main program and we do not need to manage     them per subprogram. This also means, bpf_prog_free_deferred(), which unwinds the program reference     counting and kfrees objects, needs to ensure that we don't try to double free the poke_tab when free'ing     the subprog structures. This is easily solved by NULL'ing the poke_tab pointer. The second detail is to     ensure that per subprogram JIT logic only does fixups on poke_tab[] entries it owns. To do this, we add a     pointer in the poke structure to point at the subprogram value so JITs can easily check while walking the     poke_tab structure if the current entry belongs to the current program. The aux pointer is stable and     therefore suitable for such comparison. On the jit_subprogs() error path, we omit cleaning up the     poke->aux field because these are only ever referenced from the JIT side, but on error we will never make     it to the JIT, so its fine to leave them dangling. Removing these pointers would complicate the error path     for no reason. However, we do need to untrack all poke descriptors from the main program as otherwise they     could race with the freeing of JIT memory from the subprograms. Lastly, a748c6975dea3 (bpf: propagate     poke des ---truncated--- (CVE-2021-47303)

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

The version of kernel installed on the remote host is prior to 5.10.59-52.142. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2KERNEL-5.10-2022-004 advisory.

    A flaw was found in the Linux kernel, where a BPF program can obtain sensitive information from kernel     memory via a Speculative Store Bypass side-channel attack. This issue occurs when the protection mechanism     neglects the possibility of uninitialized memory locations on the BPF stack. The highest threat from this     vulnerability is to confidentiality. (CVE-2021-34556)

    A flaw in the Linux kernel allows a privileged BPF program to obtain sensitive information from kernel     memory via a Speculative Store Bypass side-channel in the eBPF subsystem (CVE-2021-35477)

    A vulnerability was found in the Linux kernel. Missing size validations on inbound SCTP packets may allow     the kernel to read uninitialized memory. (CVE-2021-3655)

    A lack of CPU resources in the Linux kernel tracing module functionality was found in the way users use     the trace ring buffer in specific way. Only privileged local users (with CAP_SYS_ADMIN capability) could     use this flaw to starve the resources causing denial of service. (CVE-2021-3679)

    A flaw use-after-free in the Linux kernel USB High Speed Mobile Devices functionality was found in the way     user detaches USB device. A local user could use this flaw to crash the system or escalate their     privileges on the system. (CVE-2021-37159)

    ** DISPUTED ** In drivers/char/virtio_console.c in the Linux kernel before 5.13.4, data corruption or loss     can be triggered by an untrusted device that supplies a buf->len value exceeding the buffer size. NOTE:
    the vendor indicates that the cited data corruption is not a vulnerability in any existing use case; the     length validation was added solely for robustness in the face of anomalous host OS behavior.
    (CVE-2021-38160)

    A flaw was found in the hanging of mounts in the Linux kernel's NFS4 subsystem where remote servers are     unreachable for the client during migration of data from one server to another (during trunking     detection). This flaw allows a remote NFS4 server (if the client is connected) to starve the resources,     causing a denial of service. The highest threat from this vulnerability is to system availability.
    (CVE-2021-38199)

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

    ACPI: fix NULL pointer dereference (CVE-2021-47289)

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

    ipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions (CVE-2021-47291)

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

    net: sched: fix memory leak in tcindex_partial_destroy_work (CVE-2021-47295)

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

    bpf, sockmap: Fix potential memory leak on unlikely error case (CVE-2021-47298)

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

    xdp, net: Fix use-after-free in bpf_xdp_link_release (CVE-2021-47299)

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

    bpf: Fix tail_call_reachable rejection for interpreter when jit failed (CVE-2021-47300)

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

    igb: Fix use-after-free error during reset (CVE-2021-47301)

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

    bpf: Track subprog poke descriptors correctly and fix use-after-free (CVE-2021-47303)

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

    tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized (CVE-2021-47304)

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

    dma-buf/sync_file: Don't leak fences on merge failure (CVE-2021-47305)

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

    cifs: prevent NULL deref in cifs_compose_mount_options() (CVE-2021-47307)

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

    scsi: libfc: Fix array index out of bound exception (CVE-2021-47308)

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

    net: validate lwtstate->data before returning from skb_tunnel_info() (CVE-2021-47309)

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

    net: qcom/emac: fix UAF in emac_remove (CVE-2021-47311)

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

    virtio-blk: Fix memory leak among suspend/resume procedure (CVE-2021-47319)

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

    nfs: fix acl memory leak of posix_acl_create() (CVE-2021-47320)

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

    NFSv4: Fix an Oops in pnfs_mark_request_commit() when doing O_DIRECT (CVE-2021-47322)

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

    iommu/arm-smmu: Fix arm_smmu_device refcount leak in address translation (CVE-2021-47325)

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

    iommu/arm-smmu: Fix arm_smmu_device refcount leak when arm_smmu_rpm_get fails (CVE-2021-47327)

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

    scsi: iscsi: Fix conn use after free during resets (CVE-2021-47328)

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

    scsi: megaraid_sas: Fix resource leak in case of probe failure (CVE-2021-47329)

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

    fbmem: Do not delete the mode that is still in use (CVE-2021-47338)

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

    jfs: fix GPF in diFree (CVE-2021-47340)

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

    KVM: mmio: Fix use-after-free Read in kvm_vm_ioctl_unregister_coalesced_mmio (CVE-2021-47341)

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

    dm btree remove: assign new_root only when removal succeeds (CVE-2021-47343)

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

    RDMA/cma: Fix rdma_resolve_route() memory leak (CVE-2021-47345)

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

    virtio-net: Add validation for used length (CVE-2021-47352)

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

    udf: Fix NULL pointer dereference in udf_symlink function (CVE-2021-47353)

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

    drm/sched: Avoid data corruptions (CVE-2021-47354)

    An issue was discovered in the Linux kernel before 5.13.3. lib/seq_buf.c has a seq_buf_putmem_hex buffer     overflow. (CVE-2023-28772)

    A flaw was found in the Linux Kernel's memory management subsytem. In this flaw, A task is exiting and     releasing 2MB page in a vma (vm_area_struct) and hits the BUG statement in pfn_swap_entry_to_page()     referencing pmd_t x. This may allow a local user to crash the Linux kernel. (CVE-2023-4732)

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

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

ID	Name	Product	Family	Severity
268356	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-986996)	Nessus	Unity Linux Local Security Checks	high
230160	Linux Distros Unpatched Vulnerability : CVE-2021-47303	Nessus	Misc.	high
160434	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2022-004)	Nessus	Amazon Linux Local Security Checks	high

Detections

Analytics

CVE-2021-47303

high

Tenable Plugins

high

high

high