It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2024-519 advisory.
Transmit requests in Xen’s virtual network protocol can consist of multiple parts. While not really useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides a certain initial portion of the to be transferred data, these parts are directly translated into what Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of length zero, lead to a de-reference of NULL in core networking code. (CVE-2023-46838)
In the Linux kernel, the following vulnerability has been resolved: uio: Fix use-after-free in uio_open core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev)
------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock.
(CVE-2023-52439)
In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free() callbacks don’t use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with work field to reduce the size of bpf_map. (CVE-2023-52447)
In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length needs to be aligned with block size Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free. (CVE-2023-52458)
In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it, depending on actual spill size). So to check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, just use is_spilled_reg() helper.
(CVE-2023-52462)
In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04:
level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error:
Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm:
efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=–) [ 303.292123] pc : 0x0 [ 303.292443] lr :
efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29:
ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25:
ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21:
ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14:
ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10:
0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 :
0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code:
??? ??? ??? ??? (???) [ 303.310612] —[ end trace 0000000000000000 ]— Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that’s not RO if the firmware doesn’t implement SetVariable at runtime. (CVE-2023-52463)
In the Linux kernel, the following vulnerability has been resolved: mfd: syscon: Fix null pointer dereference in of_syscon_register() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. (CVE-2023-52467)
A Null pointer dereference problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return. (CVE-2023-6915)
A use-after-free vulnerability in the Linux kernel’s netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_setelem_catchall_deactivate() function checks whether the catch-all set element is active in the current generation instead of the next generation before freeing it, but only flags it inactive in the next generation, making it possible to free the element multiple times, leading to a double free vulnerability. We recommend upgrading past commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7. (CVE-2024-1085)
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
(37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 […] Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
__do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7 pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation.
(CVE-2024-26591)
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt. (CVE-2024-26598)
Note that Nessus has not tested for these issues but has instead relied only on the application’s self-reported version number.
#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
#
# The descriptive text and package checks in this plugin were
# extracted from Amazon Linux 2023 Security Advisory ALAS2023-2024-519.
##
include('compat.inc');
if (description)
{
script_id(190728);
script_version("1.6");
script_set_attribute(attribute:"plugin_modification_date", value:"2024/04/25");
script_cve_id(
"CVE-2023-46838",
"CVE-2023-52439",
"CVE-2023-52447",
"CVE-2023-52458",
"CVE-2023-52462",
"CVE-2023-52463",
"CVE-2023-52467",
"CVE-2023-6915",
"CVE-2024-1085",
"CVE-2024-26589",
"CVE-2024-26591",
"CVE-2024-26598"
);
script_name(english:"Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2024-519)");
script_set_attribute(attribute:"synopsis", value:
"The remote Amazon Linux 2023 host is missing a security update.");
script_set_attribute(attribute:"description", value:
"It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2024-519 advisory.
- Transmit requests in Xen's virtual network protocol can consist of multiple parts. While not really
useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides
a certain initial portion of the to be transferred data, these parts are directly translated into what
Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of
length zero, lead to a de-reference of NULL in core networking code. (CVE-2023-46838)
- In the Linux kernel, the following vulnerability has been resolved: uio: Fix use-after-free in uio_open
core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev
= idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release
get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev)
------------------------------------------------------- In the core-1 uio_unregister_device(), the
device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister,
put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2
will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double
freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock.
(CVE-2023-52439)
- In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when
necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed
by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of
the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most
cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free()
callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so
after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may
incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one
RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map
before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the
last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with
work field to reduce the size of bpf_map. (CVE-2023-52447)
- In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length
needs to be aligned with block size Before calling add partition or resize partition, there is no check on
whether the length is aligned with the logical block size. If the logical block size of the disk is larger
than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the
last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the
read command is smaller than the logical block size.If integrity data is supported, this will also result
in a null pointer dereference when calling bio_integrity_free. (CVE-2023-52458)
- In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt
spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set
slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it, depending on actual spill size). So to
check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid
the need to remember and double-check this in the future, just use is_spilled_reg() helper.
(CVE-2023-52462)
- In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if
SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a
callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we
never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a
crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [
303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [
303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current
EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04:
level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [
303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error:
Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core
crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm:
efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown
Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv
daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr :
efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29:
ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25:
ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21:
ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [
303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14:
ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10:
0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 :
0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [
303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [
303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585]
efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [
303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156]
el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [
303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code:
???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this
by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and
deny anything that's not RO if the firmware doesn't implement SetVariable at runtime. (CVE-2023-52463)
- In the Linux kernel, the following vulnerability has been resolved: mfd: syscon: Fix null pointer
dereference in of_syscon_register() kasprintf() returns a pointer to dynamically allocated memory which
can be NULL upon failure. (CVE-2023-52467)
- A Null pointer dereference problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may
allow an attacker using this library to cause a denial of service problem due to a missing check at a
function return. (CVE-2023-6915)
- A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to
achieve local privilege escalation. The nft_setelem_catchall_deactivate() function checks whether the
catch-all set element is active in the current generation instead of the next generation before freeing
it, but only flags it inactive in the next generation, making it possible to free the element multiple
times, leading to a double free vulnerability. We recommend upgrading past commit
b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7. (CVE-2024-1085)
- In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on
PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation.
However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not
checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx()
R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3:
(37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0,
smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5
first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise:
frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 =
1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400))
R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0)
; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and
finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...]
Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run
include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline]
bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350
net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
__do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
__x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by
rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with R7
pointer arithmetic on flow_keys prohibited. (CVE-2024-26589)
- In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in
bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp
program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with
target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL
(because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was
loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which
one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ?
page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ?
asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10
bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30
do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation.
(CVE-2024-26591)
- In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential
UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit
racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the
problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the
lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned
vgic_irq and add the corresponding decrement after queueing the interrupt. (CVE-2024-26598)
Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version
number.");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/AL2023/ALAS-2024-519.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/faqs.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2023-46838.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2023-52439.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2023-52447.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2023-52458.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2023-52462.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2023-52463.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2023-52467.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2023-6915.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2024-1085.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2024-26589.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2024-26591.html");
script_set_attribute(attribute:"see_also", value:"https://alas.aws.amazon.com/cve/html/CVE-2024-26598.html");
script_set_attribute(attribute:"solution", value:
"Run 'dnf update kernel --releasever 2023.3.20240219' to update your system.");
script_set_cvss_base_vector("CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C");
script_set_cvss_temporal_vector("CVSS2#E:U/RL:OF/RC:C");
script_set_cvss3_base_vector("CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H");
script_set_cvss3_temporal_vector("CVSS:3.0/E:U/RL:O/RC:C");
script_set_attribute(attribute:"cvss_score_source", value:"CVE-2024-26598");
script_set_attribute(attribute:"exploitability_ease", value:"No known exploits are available");
script_set_attribute(attribute:"exploit_available", value:"false");
script_set_attribute(attribute:"vuln_publication_date", value:"2024/01/31");
script_set_attribute(attribute:"patch_publication_date", value:"2024/02/15");
script_set_attribute(attribute:"plugin_publication_date", value:"2024/02/20");
script_set_attribute(attribute:"plugin_type", value:"local");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:bpftool");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:bpftool-debuginfo");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-debuginfo");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-debuginfo-common-aarch64");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-debuginfo-common-x86_64");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-devel");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-headers");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-libbpf");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-libbpf-devel");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-libbpf-static");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-livepatch-6.1.75-99.163");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-modules-extra");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-modules-extra-common");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-tools");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-tools-debuginfo");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:kernel-tools-devel");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:perf");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:perf-debuginfo");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:python3-perf");
script_set_attribute(attribute:"cpe", value:"p-cpe:/a:amazon:linux:python3-perf-debuginfo");
script_set_attribute(attribute:"cpe", value:"cpe:/o:amazon:linux:2023");
script_set_attribute(attribute:"generated_plugin", value:"current");
script_end_attributes();
script_category(ACT_GATHER_INFO);
script_family(english:"Amazon Linux Local Security Checks");
script_copyright(english:"This script is Copyright (C) 2024 and is owned by Tenable, Inc. or an Affiliate thereof.");
script_dependencies("ssh_get_info.nasl", "kpatch.nasl");
script_require_keys("Host/local_checks_enabled", "Host/AmazonLinux/release", "Host/AmazonLinux/rpm-list");
exit(0);
}
include("rpm.inc");
include("hotfixes.inc");
if (!get_kb_item("Host/local_checks_enabled")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);
var alas_release = get_kb_item("Host/AmazonLinux/release");
if (isnull(alas_release) || !strlen(alas_release)) audit(AUDIT_OS_NOT, "Amazon Linux");
var os_ver = pregmatch(pattern: "^AL(A|\d+|-\d+)", string:alas_release);
if (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, "Amazon Linux");
os_ver = os_ver[1];
if (os_ver != "-2023")
{
if (os_ver == 'A') os_ver = 'AMI';
audit(AUDIT_OS_NOT, "Amazon Linux 2023", "Amazon Linux " + os_ver);
}
if (!get_kb_item("Host/AmazonLinux/rpm-list")) audit(AUDIT_PACKAGE_LIST_MISSING);
if (get_one_kb_item("Host/kpatch/kernel-cves"))
{
set_hotfix_type("kpatch");
var cve_list = make_list("CVE-2023-6915", "CVE-2023-46838", "CVE-2023-52439", "CVE-2023-52447", "CVE-2023-52458", "CVE-2023-52462", "CVE-2023-52463", "CVE-2023-52467", "CVE-2024-1085", "CVE-2024-26589", "CVE-2024-26591", "CVE-2024-26598");
if (hotfix_cves_check(cve_list))
{
audit(AUDIT_PATCH_INSTALLED, "kpatch hotfix for ALAS2023-2024-519");
}
else
{
__rpm_report = hotfix_reporting_text();
}
}
var pkgs = [
{'reference':'bpftool-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'bpftool-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'bpftool-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'bpftool-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-debuginfo-common-aarch64-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-debuginfo-common-x86_64-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-devel-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-devel-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-headers-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-headers-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-libbpf-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-libbpf-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-libbpf-devel-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-libbpf-devel-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-libbpf-static-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-libbpf-static-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-livepatch-6.1.75-99.163-1.0-0.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-livepatch-6.1.75-99.163-1.0-0.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-modules-extra-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-modules-extra-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-modules-extra-common-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-modules-extra-common-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-devel-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'kernel-tools-devel-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'perf-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'perf-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'perf-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'perf-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'python3-perf-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'python3-perf-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'python3-perf-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'aarch64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE},
{'reference':'python3-perf-debuginfo-6.1.75-99.163.amzn2023', 'cpu':'x86_64', 'release':'AL-2023', 'rpm_spec_vers_cmp':TRUE}
];
var flag = 0;
foreach var package_array ( pkgs ) {
var reference = NULL;
var _release = NULL;
var sp = NULL;
var _cpu = NULL;
var el_string = NULL;
var rpm_spec_vers_cmp = NULL;
var epoch = NULL;
var allowmaj = NULL;
var exists_check = NULL;
if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];
if (!empty_or_null(package_array['release'])) _release = package_array['release'];
if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];
if (!empty_or_null(package_array['cpu'])) _cpu = package_array['cpu'];
if (!empty_or_null(package_array['el_string'])) el_string = package_array['el_string'];
if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];
if (!empty_or_null(package_array['epoch'])) epoch = package_array['epoch'];
if (!empty_or_null(package_array['allowmaj'])) allowmaj = package_array['allowmaj'];
if (!empty_or_null(package_array['exists_check'])) exists_check = package_array['exists_check'];
if (reference && _release && (!exists_check || rpm_exists(release:_release, rpm:exists_check))) {
if (rpm_check(release:_release, sp:sp, cpu:_cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;
}
}
if (flag)
{
security_report_v4(
port : 0,
severity : SECURITY_WARNING,
extra : rpm_report_get()
);
exit(0);
}
else
{
var tested = pkg_tests_get();
if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);
else audit(AUDIT_PACKAGE_NOT_INSTALLED, "bpftool / bpftool-debuginfo / kernel / etc");
}
Vendor | Product | Version | CPE |
---|---|---|---|
amazon | linux | kernel | p-cpe:/a:amazon:linux:kernel |
amazon | linux | kernel-debuginfo | p-cpe:/a:amazon:linux:kernel-debuginfo |
amazon | linux | kernel-debuginfo-common-x86_64 | p-cpe:/a:amazon:linux:kernel-debuginfo-common-x86_64 |
amazon | linux | kernel-devel | p-cpe:/a:amazon:linux:kernel-devel |
amazon | linux | kernel-headers | p-cpe:/a:amazon:linux:kernel-headers |
amazon | linux | kernel-tools | p-cpe:/a:amazon:linux:kernel-tools |
amazon | linux | kernel-tools-debuginfo | p-cpe:/a:amazon:linux:kernel-tools-debuginfo |
amazon | linux | kernel-tools-devel | p-cpe:/a:amazon:linux:kernel-tools-devel |
amazon | linux | perf | p-cpe:/a:amazon:linux:perf |
amazon | linux | perf-debuginfo | p-cpe:/a:amazon:linux:perf-debuginfo |
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-46838
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52439
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52447
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52458
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52462
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52463
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52467
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6915
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-1085
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26589
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26591
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26598
alas.aws.amazon.com/AL2023/ALAS-2024-519.html
alas.aws.amazon.com/cve/html/CVE-2023-46838.html
alas.aws.amazon.com/cve/html/CVE-2023-52439.html
alas.aws.amazon.com/cve/html/CVE-2023-52447.html
alas.aws.amazon.com/cve/html/CVE-2023-52458.html
alas.aws.amazon.com/cve/html/CVE-2023-52462.html
alas.aws.amazon.com/cve/html/CVE-2023-52463.html
alas.aws.amazon.com/cve/html/CVE-2023-52467.html
alas.aws.amazon.com/cve/html/CVE-2023-6915.html
alas.aws.amazon.com/cve/html/CVE-2024-1085.html
alas.aws.amazon.com/cve/html/CVE-2024-26589.html
alas.aws.amazon.com/cve/html/CVE-2024-26591.html
alas.aws.amazon.com/cve/html/CVE-2024-26598.html
alas.aws.amazon.com/faqs.html