This CPE summary could be partial or incomplete. Please contact us for a detailed listing.

Summary

Detail
Vendor Linux First view 2014-02-28
Product Linux Kernel Last view 2024-02-27
Version 3.18.32 Type Os
Update *  
Edition *  
Language *  
Sofware Edition *  
Target Software *  
Target Hardware *  
Other *  
 
CPE Product cpe:2.3:o:linux:linux_kernel

Activity : Overall

Related : CVE

This CPE have more than 25 Relations. If you want to see a complete summary for this CPE, please contact us.
  Date Alert Description
7.1 2024-02-27 CVE-2021-46954

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

net/sched: sch_frag: fix stack OOB read while fragmenting IPv4 packets

when 'act_mirred' tries to fragment IPv4 packets that had been previously re-assembled using 'act_ct', splats like the following can be observed on kernels built with KASAN:

BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60
Read of size 1 at addr ffff888147009574 by task ping/947

CPU: 0 PID: 947 Comm: ping Not tainted 5.12.0-rc6+ #418
Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
Call Trace:

dump_stack+0x92/0xc1
print_address_description.constprop.7+0x1a/0x150
kasan_report.cold.13+0x7f/0x111
ip_do_fragment+0x1b03/0x1f60
sch_fragment+0x4bf/0xe40
tcf_mirred_act+0xc3d/0x11a0 [act_mirred]
tcf_action_exec+0x104/0x3e0
fl_classify+0x49a/0x5e0 [cls_flower]
tcf_classify_ingress+0x18a/0x820
__netif_receive_skb_core+0xae7/0x3340
__netif_receive_skb_one_core+0xb6/0x1b0
process_backlog+0x1ef/0x6c0
__napi_poll+0xaa/0x500
net_rx_action+0x702/0xac0
__do_softirq+0x1e4/0x97f
do_softirq+0x71/0x90

__local_bh_enable_ip+0xdb/0xf0
ip_finish_output2+0x760/0x2120
ip_do_fragment+0x15a5/0x1f60
__ip_finish_output+0x4c2/0xea0
ip_output+0x1ca/0x4d0
ip_send_skb+0x37/0xa0
raw_sendmsg+0x1c4b/0x2d00
sock_sendmsg+0xdb/0x110
__sys_sendto+0x1d7/0x2b0
__x64_sys_sendto+0xdd/0x1b0
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f82e13853eb
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89
RSP: 002b:00007ffe01fad888 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00005571aac13700 RCX: 00007f82e13853eb
RDX: 0000000000002330 RSI: 00005571aac13700 RDI: 0000000000000003
RBP: 0000000000002330 R08: 00005571aac10500 R09: 0000000000000010
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe01faefb0
R13: 00007ffe01fad890 R14: 00007ffe01fad980 R15: 00005571aac0f0a0

The buggy address belongs to the page:
page:000000001dff2e03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x147009
flags: 0x17ffffc0001000(reserved)
raw: 0017ffffc0001000 ffffea00051c0248 ffffea00051c0248 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff888147009400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888147009480: f1 f1 f1 f1 04 f2 f2 f2 f2 f2 f2 f2 00 00 00 00
>ffff888147009500: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2
^
ffff888147009580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888147009600: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2

for IPv4 packets, sch_fragment() uses a temporary struct dst_entry. Then, in the following call graph:

ip_do_fragment()
ip_skb_dst_mtu()
ip_dst_mtu_maybe_forward()
ip_mtu_locked()

the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in sch_fragment(), similarly to what is done for IPv6 few lines below.

6.7 2024-02-27 CVE-2021-46953

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

ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure

When failing the driver probe because of invalid firmware properties, the GTDT driver unmaps the interrupt that it mapped earlier.

However, it never checks whether the mapping of the interrupt actially succeeded. Even more, should the firmware report an illegal interrupt number that overlaps with the GIC SGI range, this can result in an IPI being unmapped, and subsequent fireworks (as reported by Dann Frazier).

Rework the driver to have a slightly saner behaviour and actually check whether the interrupt has been mapped before unmapping things.

7.1 2024-02-27 CVE-2021-46952

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

NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds

Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused by a garbage timeout (retrans) mount option being passed to nfs mount, in this case from syzkaller.

If the protocol is XPRT_TRANSPORT_UDP, then 'retrans' is a shift value for a 64-bit long integer, so 'retrans' cannot be >= 64. If it is >= 64, fail the mount and return an error.

5.5 2024-02-27 CVE-2021-46951

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

tpm: efi: Use local variable for calculating final log size

When tpm_read_log_efi is called multiple times, which happens when one loads and unloads a TPM2 driver multiple times, then the global variable efi_tpm_final_log_size will at some point become a negative number due to the subtraction of final_events_preboot_size occurring each time. Use a local variable to avoid this integer underflow.

The following issue is now resolved:

Mar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Mar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20 Mar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 Mar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 Mar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f Mar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d Mar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073 Mar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 Mar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 Mar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000 Mar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 Mar 8 15:35:12 hibinst kernel: Call Trace: Mar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7 Mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 Mar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260 Mar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370 Mar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0 Mar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370

7.8 2024-02-27 CVE-2021-46950

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

md/raid1: properly indicate failure when ending a failed write request

This patch addresses a data corruption bug in raid1 arrays using bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared.

Since we are in the failure leg of raid1_end_write_request, the request either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).

5.5 2024-02-27 CVE-2021-46949

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

sfc: farch: fix TX queue lookup in TX flush done handling

We're starting from a TXQ instance number ('qid'), not a TXQ type, so
efx_get_tx_queue() is inappropriate (and could return NULL, leading
to panics).

5.5 2024-02-27 CVE-2021-46948

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

sfc: farch: fix TX queue lookup in TX event handling

We're starting from a TXQ label, not a TXQ type, so
efx_channel_get_tx_queue() is inappropriate (and could return NULL,
leading to panics).

5.5 2024-02-27 CVE-2021-46947

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

sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues

efx->xdp_tx_queue_count is initially initialized to num_possible_cpus() and is later used to allocate and traverse efx->xdp_tx_queues lookup array. However, we may end up not initializing all the array slots with real queues during probing. This results, for example, in a NULL pointer dereference, when running "# ethtool -S ", similar to below

[2570283.664955][T4126959] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [2570283.681283][T4126959] #PF: supervisor read access in kernel mode [2570283.695678][T4126959] #PF: error_code(0x0000) - not-present page [2570283.710013][T4126959] PGD 0 P4D 0 [2570283.721649][T4126959] Oops: 0000 [#1] SMP PTI [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G O 5.10.20-cloudflare-2021.3.1 #1 [2570283.752641][T4126959] Hardware name: [2570283.781408][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b [2570283.831259][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202 [2570283.845121][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018 [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd970ce000 RDI: 0000000000000005 [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8 [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:0000000000000000 [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2570283.952524][T4126959] CR2: 00000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706e0 [2570283.967529][T4126959] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2570283.997308][T4126959] PKRU: 55555554 [2570284.007649][T4126959] Call Trace: [2570284.017598][T4126959] dev_ethtool+0x1832/0x2830

Fix this by adjusting efx->xdp_tx_queue_count after probing to reflect the true value of initialized slots in efx->xdp_tx_queues.

5.5 2024-02-27 CVE-2021-46945

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

ext4: always panic when errors=panic is specified

Before commit 014c9caa29d3 ("ext4: make ext4_abort() use __ext4_error()"), the following series of commands would trigger a panic:

1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test

After commit 014c9caa29d3, remounting a file system using the test mount option "abort" will no longer trigger a panic. This commit will restore the behaviour immediately before commit 014c9caa29d3. (However, note that the Linux kernel's behavior has not been consistent; some previous kernel versions, including 5.4 and 4.19 similarly did not panic after using the mount option "abort".)

This also makes a change to long-standing behaviour; namely, the following series commands will now cause a panic, when previously it did not:

1. mount /dev/sda -o ro,errors=panic test 2. echo test > /sys/fs/ext4/sda/trigger_fs_error

However, this makes ext4's behaviour much more consistent, so this is a good thing.

5.5 2024-02-27 CVE-2021-46944

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

media: staging/intel-ipu3: Fix memory leak in imu_fmt

We are losing the reference to an allocated memory if try. Change the order of the check to avoid that.

7.8 2024-02-27 CVE-2021-46943

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

media: staging/intel-ipu3: Fix set_fmt error handling

If there in an error during a set_fmt, do not overwrite the previous sizes with the invalid config.

Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and causing the following OOPs

[ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes) [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP

5.5 2024-02-27 CVE-2021-46942

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

io_uring: fix shared sqpoll cancellation hangs

[ 736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds. [ 736.982897] Call Trace: [ 736.982901] schedule+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720

We call io_uring_cancel_sqpoll() one by one for each ctx either in sq_thread() itself or via task works, and it's intended to cancel all requests of a specified context. However the function uses per-task counters to track the number of inflight requests, so it counts more requests than available via currect io_uring ctx and goes to sleep for them to appear (e.g. from IRQ), that will never happen.

Cancel a bit more than before, i.e. all ctxs that share sqpoll and continue to use shared counters. Don't forget that we should not remove ctx from the list before running that task_work sqpoll-cancel, otherwise the function wouldn't be able to find the context and will hang.

5.5 2024-02-27 CVE-2021-46941

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

usb: dwc3: core: Do core softreset when switch mode

According to the programming guide, to switch mode for DRD controller, the driver needs to do the following.

To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence

To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence

Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2].

So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device.

[1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/

5.5 2024-02-27 CVE-2021-46940

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

tools/power turbostat: Fix offset overflow issue in index converting

The idx_to_offset() function returns type int (32-bit signed), but MSR_PKG_ENERGY_STAT is u32 and would be interpreted as a negative number. The end result is that it hits the if (offset < 0) check in update_msr_sum() which prevents the timer callback from updating the stat in the background when long durations are used. The similar issue exists in offset_to_idx() and update_msr_sum(). Fix this issue by converting the 'int' to 'off_t' accordingly.

5.5 2024-02-27 CVE-2021-46939

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

tracing: Restructure trace_clock_global() to never block

It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case:

Call Trace:
trace_clock_global+0x91/0xa0
__rb_reserve_next+0x237/0x460
ring_buffer_lock_reserve+0x12a/0x3f0
trace_buffer_lock_reserve+0x10/0x50
__trace_graph_return+0x1f/0x80
trace_graph_return+0xb7/0xf0
? trace_clock_global+0x91/0xa0
ftrace_return_to_handler+0x8b/0xf0
? pv_hash+0xa0/0xa0
return_to_handler+0x15/0x30
? ftrace_graph_caller+0xa0/0xa0
? trace_clock_global+0x91/0xa0
? __rb_reserve_next+0x237/0x460
? ring_buffer_lock_reserve+0x12a/0x3f0
? trace_event_buffer_lock_reserve+0x3c/0x120
? trace_event_buffer_reserve+0x6b/0xc0
? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0
? dpm_run_callback+0x3b/0xc0
? pm_ops_is_empty+0x50/0x50
? platform_get_irq_byname_optional+0x90/0x90
? trace_device_pm_callback_start+0x82/0xd0
? dpm_run_callback+0x49/0xc0

With the following RIP:

RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200

Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again:

ring_buffer_lock_reserve() {
trace_clock_global() {
arch_spin_lock() {
queued_spin_lock_slowpath() {
/* lock taken */
(something else gets traced by function graph tracer)
ring_buffer_lock_reserve() {
trace_clock_global() {
arch_spin_lock() {
queued_spin_lock_slowpath() {
/* DEAD LOCK! */

Tracing should *never* block, as it can lead to strange lockups like the above.

Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded "prev_time" simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

7.8 2024-02-27 CVE-2021-46938

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

dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails

When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free.

E.g. (dmesg):
device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device
device-mapper: ioctl: unable to set up device queue for new table.
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0305e098835de000 TEID: 0305e098835de803
Fault in home space mode while using kernel ASCE.
AS:000000025efe0007 R3:0000000000000024
Oops: 0038 ilc:3 [#1] SMP
Modules linked in: ... lots of modules ...
Supported: Yes, External
CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3
Hardware name: IBM 8561 T01 7I2 (LPAR)
Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000
000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000
000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640
00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8
Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8
000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58
#000000025e368ec4: e3b010000008 ag %r11,0(%r1)
>000000025e368eca: e310b0080004 lg %r1,8(%r11)
000000025e368ed0: a7110001 tmll %r1,1
000000025e368ed4: a7740129 brc 7,25e369126
000000025e368ed8: e320b0080004 lg %r2,8(%r11)
000000025e368ede: b904001b lgr %r1,%r11
Call Trace:
[<000000025e368eca>] kfree+0x42/0x330
[<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8
[<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod]
[<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod]
[<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod]
[<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod]
[<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod]
[<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod]
[<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0
[<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40
[<000000025e8c15ac>] system_call+0xd8/0x2c8
Last Breaking-Event-Address:
[<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8
Kernel panic - not syncing: Fatal exception: panic_on_oops

When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again.

Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().

5.5 2024-02-27 CVE-2021-46937

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

mm/damon/dbgfs: fix 'struct pid' leaks in 'dbgfs_target_ids_write()'

DAMON debugfs interface increases the reference counts of 'struct pid's for targets from the 'target_ids' file write callback ('dbgfs_target_ids_write()'), but decreases the counts only in DAMON monitoring termination callback ('dbgfs_before_terminate()').

Therefore, when 'target_ids' file is repeatedly written without DAMON monitoring start/termination, the reference count is not decreased and therefore memory for the 'struct pid' cannot be freed. This commit fixes this issue by decreasing the reference counts when 'target_ids' is written.

7.8 2024-02-27 CVE-2021-46936

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

net: fix use-after-free in tw_timer_handler

A real world panic issue was found as follow in Linux 5.4.

BUG: unable to handle page fault for address: ffffde49a863de28
PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
RIP: 0010:tw_timer_handler+0x20/0x40
Call Trace:

call_timer_fn+0x2b/0x120
run_timer_softirq+0x1ef/0x450
__do_softirq+0x10d/0x2b8
irq_exit+0xc7/0xd0
smp_apic_timer_interrupt+0x68/0x120
apic_timer_interrupt+0xf/0x20

This issue was also reported since 2017 in the thread [1], unfortunately, the issue was still can be reproduced after fixing DCCP.

The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some inflight time-wait timers.

This bug is not introduced by commit f2bf415cfed7 ("mib: add net to NET_ADD_STATS_BH") since the net_statistics is a global variable instead of dynamic allocation and freeing. Actually, commit 61a7e26028b9 ("mib: put net statistics on struct net") introduces the bug since it put net statistics on struct net and free it when net namespace is destroyed.

Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is meaningless when init_ipv4_mibs() fails.

[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1

5.5 2024-02-27 CVE-2021-46935

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

binder: fix async_free_space accounting for empty parcels

In 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area shared with user space") fixed a kernel structure visibility issue. As part of that patch, sizeof(void *) was used as the buffer size for 0-length data payloads so the driver could detect abusive clients sending 0-length asynchronous transactions to a server by enforcing limits on async_free_size.

Unfortunately, on the "free" side, the accounting of async_free_space did not add the sizeof(void *) back. The result was that up to 8-bytes of async_free_space were leaked on every async transaction of 8-bytes or less. These small transactions are uncommon, so this accounting issue has gone undetected for several years.

The fix is to use "buffer_size" (the allocated buffer size) instead of "size" (the logical buffer size) when updating the async_free_space during the free operation. These are the same except for this corner case of asynchronous transactions with payloads < 8 bytes.

3.3 2024-02-27 CVE-2021-46934

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

i2c: validate user data in compat ioctl

Wrong user data may cause warning in i2c_transfer(), ex: zero msgs. Userspace should not be able to trigger warnings, so this patch adds validation checks for user data in compact ioctl to prevent reported warnings

5.5 2024-02-27 CVE-2021-46933

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

usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.

ffs_data_clear is indirectly called from both ffs_fs_kill_sb and ffs_ep0_release, so it ends up being called twice when userland closes ep0 and then unmounts f_fs. If userland provided an eventfd along with function's USB descriptors, it ends up calling eventfd_ctx_put as many times, causing a refcount underflow. NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls.

Also, set epfiles to NULL right after de-allocating it, for readability.

For completeness, ffs_data_clear actually ends up being called thrice, the last call being before the whole ffs structure gets freed, so when this specific sequence happens there is a second underflow happening (but not being reported):

/sys/kernel/debug/tracing# modprobe usb_f_fs /sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter /sys/kernel/debug/tracing# echo function > current_tracer /sys/kernel/debug/tracing# echo 1 > tracing_on (setup gadget, run and kill function userland process, teardown gadget) /sys/kernel/debug/tracing# echo 0 > tracing_on /sys/kernel/debug/tracing# cat trace
smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed
smartcard-openp-431 [000] ..... 1946.279147: ffs_data_clear <-ffs_data_closed
smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear <-ffs_data_put

Warning output corresponding to above trace: [ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c [ 1946.293094] refcount_t: underflow; use-after-free. [ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) [ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G C OE 5.15.0-1-rpi #1 Debian 5.15.3-1 [ 1946.417950] Hardware name: BCM2835 [ 1946.425442] Backtrace: [ 1946.432048] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c [ 1946.458412] [] (show_stack) from [] (dump_stack+0x28/0x30) [ 1946.470380] [] (dump_stack) from [] (__warn+0xe8/0x154) [ 1946.482067] r5:c04a948c r4:c0a71dc8 [ 1946.490184] [] (__warn) from [] (warn_slowpath_fmt+0xa0/0xe4) [ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04 [ 1946.517070] [] (warn_slowpath_fmt) from [] (refcount_warn_saturate+0x110/0x15c) [ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0 [ 1946.546708] [] (refcount_warn_saturate) from [] (eventfd_ctx_put+0x48/0x74) [ 1946.564476] [] (eventfd_ctx_put) from [] (ffs_data_clear+0xd0/0x118 [usb_f_fs]) [ 1946.582664] r5:c3b84c00 r4:c2695b00 [ 1946.590668] [] (ffs_data_clear [usb_f_fs]) from [] (ffs_data_closed+0x9c/0x150 [usb_f_fs]) [ 1946.609608] r5:bf54d014 r4:c2695b00 [ 1946.617522] [] (ffs_data_closed [usb_f_fs]) from [] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs]) [ 1946.636217] r7:c0dfcb ---truncated---

5.5 2024-02-27 CVE-2021-46932

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

Input: appletouch - initialize work before device registration

Syzbot has reported warning in __flush_work(). This warning is caused by work->func == NULL, which means missing work initialization.

This may happen, since input_dev->close() calls cancel_work_sync(&dev->work), but dev->work initalization happens _after_ input_register_device() call.

So this patch moves dev->work initialization before registering input device

5.5 2024-02-27 CVE-2021-46931

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

net/mlx5e: Wrap the tx reporter dump callback to extract the sq

Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually of type struct mlx5e_tx_timeout_ctx *.

mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected
mlx5_core 0000:08:00.1 enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last trans: 21565000
BUG: stack guard page was hit at 0000000093f1a2de (stack is 00000000b66ea0dc..000000004d932dae)
kernel stack overflow (page fault): 0000 [#1] SMP NOPTI
CPU: 5 PID: 95 Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Workqueue: mlx5e mlx5e_tx_timeout_work [mlx5_core]
RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180
[mlx5_core]
Call Trace:
mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core]
devlink_health_do_dump.part.91+0x71/0xd0
devlink_health_report+0x157/0x1b0
mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core]
? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0
[mlx5_core]
? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core]
? update_load_avg+0x19b/0x550
? set_next_entity+0x72/0x80
? pick_next_task_fair+0x227/0x340
? finish_task_switch+0xa2/0x280
mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core]
process_one_work+0x1de/0x3a0
worker_thread+0x2d/0x3c0
? process_one_work+0x3a0/0x3a0
kthread+0x115/0x130
? kthread_park+0x90/0x90
ret_from_fork+0x1f/0x30
--[ end trace 51ccabea504edaff ]---
RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180
PKRU: 55555554
Kernel panic - not syncing: Fatal exception
Kernel Offset: disabled
end Kernel panic - not syncing: Fatal exception

To fix this bug add a wrapper for mlx5e_tx_reporter_dump_sq() which extracts the sq from struct mlx5e_tx_timeout_ctx and set it as the TX-timeout-recovery flow dump callback.

5.5 2024-02-27 CVE-2021-46930

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

usb: mtu3: fix list_head check warning

This is caused by uninitialization of list_head.

BUG: KASAN: use-after-free in __list_del_entry_valid+0x34/0xe4

Call trace: dump_backtrace+0x0/0x298 show_stack+0x24/0x34 dump_stack+0x130/0x1a8 print_address_description+0x88/0x56c __kasan_report+0x1b8/0x2a0 kasan_report+0x14/0x20 __asan_load8+0x9c/0xa0 __list_del_entry_valid+0x34/0xe4 mtu3_req_complete+0x4c/0x300 [mtu3] mtu3_gadget_stop+0x168/0x448 [mtu3] usb_gadget_unregister_driver+0x204/0x3a0 unregister_gadget_item+0x44/0xa4

5.5 2024-02-27 CVE-2021-46929

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

sctp: use call_rcu to free endpoint

This patch is to delay the endpoint free by calling call_rcu() to fix another use-after-free issue in sctp_sock_dump():

BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20
Call Trace:
__lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:334 [inline]
__lock_sock+0x203/0x350 net/core/sock.c:2253
lock_sock_nested+0xfe/0x120 net/core/sock.c:2774
lock_sock include/net/sock.h:1492 [inline]
sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324
sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091
sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
__inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049
inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065
netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244
__netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352
netlink_dump_start include/linux/netlink.h:216 [inline]
inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170
__sock_diag_cmd net/core/sock_diag.c:232 [inline]
sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477
sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274

This issue occurs when asoc is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk).

To prevent the sk free, as a holder of the sk, ep should be alive when calling lock_sock(). This patch uses call_rcu() and moves sock_put and ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try to hold the ep under rcu_read_lock in sctp_transport_traverse_process().

If sctp_endpoint_hold() returns true, it means this ep is still alive and we have held it and can continue to dump it; If it returns false, it means this ep is dead and can be freed after rcu_read_unlock, and we should skip it.

In sctp_sock_dump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this dumping, this asoc was peeled off before calling lock_sock(), and the sk should be skipped; If this ep is the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to lock_sock, no peeloff will happen either until release_sock.

Note that delaying endpoint free won't delay the port release, as the port release happens in sctp_endpoint_destroy() before calling call_rcu(). Also, freeing endpoint by call_rcu() makes it safe to access the sk by asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().

Thanks Jones to bring this issue up.

v1->v2:
- improve the changelog.
- add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.

CWE : Common Weakness Enumeration

This CPE have more than 25 Relations. If you want to see a complete summary for this CPE, please contact us.
%idName
20% (326) CWE-416 Use After Free
12% (196) CWE-476 NULL Pointer Dereference
9% (149) CWE-362 Race Condition
7% (115) CWE-787 Out-of-bounds Write
6% (102) CWE-125 Out-of-bounds Read
5% (93) CWE-401 Failure to Release Memory Before Removing Last Reference ('Memory L...
5% (88) CWE-119 Failure to Constrain Operations within the Bounds of a Memory Buffer
4% (70) CWE-200 Information Exposure
2% (48) CWE-190 Integer Overflow or Wraparound
2% (44) CWE-20 Improper Input Validation
1% (31) CWE-415 Double Free
1% (24) CWE-264 Permissions, Privileges, and Access Controls
1% (23) CWE-667 Insufficient Locking
1% (19) CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflo...
1% (18) CWE-399 Resource Management Errors
1% (17) CWE-400 Uncontrolled Resource Consumption ('Resource Exhaustion')
0% (12) CWE-665 Improper Initialization
0% (12) CWE-269 Improper Privilege Management
0% (11) CWE-772 Missing Release of Resource after Effective Lifetime
0% (10) CWE-369 Divide By Zero
0% (10) CWE-284 Access Control (Authorization) Issues
0% (9) CWE-770 Allocation of Resources Without Limits or Throttling
0% (9) CWE-755 Improper Handling of Exceptional Conditions
0% (8) CWE-122 Heap-based Buffer Overflow
0% (7) CWE-668 Exposure of Resource to Wrong Sphere

SAINT Exploits

Description Link
Ubuntu overlayfs privilege elevation More info here
Linux Dirty COW Local File Overwrite More info here

Snort® IPS/IDS

This CPE have more than 25 Relations. If you want to see a complete summary for this CPE, please contact us.
Date Description
2020-11-19 Linux kernel af_packet tpacket_rcv integer overflow attempt
RuleID : 56052 - Type : OS-LINUX - Revision : 1
2020-11-19 Linux kernel af_packet tpacket_rcv integer overflow attempt
RuleID : 56051 - Type : OS-LINUX - Revision : 1
2017-11-21 Linux kernel nfsd nfsd4_layout_verify out of bounds read attempt
RuleID : 44638 - Type : PROTOCOL-RPC - Revision : 1
2017-11-21 Linux kernel nfsd nfsd4_layout_verify out of bounds read attempt
RuleID : 44637 - Type : PROTOCOL-RPC - Revision : 1
2017-08-24 Linux kernel SCTP invalid chunk length denial of service attempt
RuleID : 43692 - Type : OS-LINUX - Revision : 1
2017-07-18 Linux kernel NFSv3 malformed WRITE arbitrary memory read attempt
RuleID : 43189 - Type : PROTOCOL-RPC - Revision : 2
2017-07-18 Linux kernel NFSv2 malformed WRITE arbitrary memory read attempt
RuleID : 43188 - Type : PROTOCOL-RPC - Revision : 2
2017-01-18 Linux net af_packet.c tpacket version race condition use after free attempt
RuleID : 41028 - Type : OS-LINUX - Revision : 2
2017-01-18 Linux net af_packet.c tpacket version race condition use after free attempt
RuleID : 41027 - Type : OS-LINUX - Revision : 2
2016-11-30 Linux kernel madvise race condition attempt
RuleID : 40566 - Type : OS-LINUX - Revision : 2
2016-11-30 Linux kernel madvise race condition attempt
RuleID : 40565 - Type : OS-LINUX - Revision : 2
2016-11-30 Linux kernel madvise race condition attempt
RuleID : 40564 - Type : OS-LINUX - Revision : 2
2016-11-30 Linux kernel madvise race condition attempt
RuleID : 40563 - Type : OS-LINUX - Revision : 2
2016-11-30 Linux kernel madvise race condition attempt
RuleID : 40562 - Type : OS-LINUX - Revision : 2
2016-11-30 Linux kernel madvise race condition attempt
RuleID : 40561 - Type : OS-LINUX - Revision : 2
2016-11-30 Linux kernel madvise race condition attempt
RuleID : 40560 - Type : OS-LINUX - Revision : 2
2016-11-30 Linux kernel madvise race condition attempt
RuleID : 40543 - Type : OS-LINUX - Revision : 2
2016-11-30 Linux kernel madvise race condition attempt
RuleID : 40542 - Type : OS-LINUX - Revision : 2
2018-05-23 Linux Kernel Challenge ACK provocation attempt
RuleID : 40063-community - Type : OS-LINUX - Revision : 5
2016-10-11 Linux Kernel Challenge ACK provocation attempt
RuleID : 40063 - Type : OS-LINUX - Revision : 5
2016-09-17 Linux Kernel USBIP out of bounds write attempt
RuleID : 39894 - Type : OS-LINUX - Revision : 4
2016-09-17 Linux Kernel USBIP out of bounds write attempt
RuleID : 39893 - Type : OS-LINUX - Revision : 4
2016-03-14 Linux Kernel keyring object exploit download attempt
RuleID : 37438 - Type : OS-LINUX - Revision : 2
2016-03-14 Linux Kernel keyring object exploit download attempt
RuleID : 37437 - Type : OS-LINUX - Revision : 2
2016-03-14 Linux Kernel keyring object exploit download attempt
RuleID : 37436 - Type : OS-LINUX - Revision : 2

Nessus® Vulnerability Scanner

This CPE have more than 25 Relations. If you want to see a complete summary for this CPE, please contact us.
id Description
2019-01-17 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2019-509c133845.nasl - Type: ACT_GATHER_INFO
2019-01-17 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2019-f812c9fb22.nasl - Type: ACT_GATHER_INFO
2019-01-15 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2019-337484d88b.nasl - Type: ACT_GATHER_INFO
2019-01-15 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2019-b0f7a7b74b.nasl - Type: ACT_GATHER_INFO
2019-01-14 Name: The remote Virtuozzo host is missing multiple security updates.
File: Virtuozzo_VZA-2016-104.nasl - Type: ACT_GATHER_INFO
2019-01-14 Name: The remote Amazon Linux AMI host is missing a security update.
File: ala_ALAS-2019-1145.nasl - Type: ACT_GATHER_INFO
2019-01-11 Name: The remote Virtuozzo host is missing a security update.
File: Virtuozzo_VZA-2018-072.nasl - Type: ACT_GATHER_INFO
2019-01-11 Name: The remote Virtuozzo host is missing multiple security updates.
File: Virtuozzo_VZA-2018-075.nasl - Type: ACT_GATHER_INFO
2019-01-11 Name: The remote Virtuozzo host is missing a security update.
File: Virtuozzo_VZA-2018-077.nasl - Type: ACT_GATHER_INFO
2019-01-11 Name: The remote Virtuozzo host is missing a security update.
File: Virtuozzo_VZA-2018-085.nasl - Type: ACT_GATHER_INFO
2019-01-11 Name: The remote Virtuozzo host is missing a security update.
File: Virtuozzo_VZA-2018-086.nasl - Type: ACT_GATHER_INFO
2019-01-11 Name: The remote Virtuozzo host is missing a security update.
File: Virtuozzo_VZA-2018-088.nasl - Type: ACT_GATHER_INFO
2019-01-11 Name: The remote Virtuozzo host is missing a security update.
File: Virtuozzo_VZA-2018-089.nasl - Type: ACT_GATHER_INFO
2019-01-10 Name: The remote Amazon Linux 2 host is missing a security update.
File: al2_ALAS-2019-1145.nasl - Type: ACT_GATHER_INFO
2019-01-10 Name: The remote device is affected by multiple vulnerabilities.
File: juniper_space_jsa10917_183R1.nasl - Type: ACT_GATHER_INFO
2019-01-10 Name: The remote device is affected by multiple vulnerabilities.
File: juniper_space_jsa10917_184R1.nasl - Type: ACT_GATHER_INFO
2019-01-03 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2018-0edb45d9db.nasl - Type: ACT_GATHER_INFO
2019-01-03 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2018-1621b2204a.nasl - Type: ACT_GATHER_INFO
2019-01-03 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2018-272cf2f9f4.nasl - Type: ACT_GATHER_INFO
2019-01-03 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2018-2c6bd93875.nasl - Type: ACT_GATHER_INFO
2019-01-03 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2018-3857a8b41a.nasl - Type: ACT_GATHER_INFO
2019-01-03 Name: The remote Fedora host is missing a security update.
File: fedora_2018-50075276e8.nasl - Type: ACT_GATHER_INFO
2019-01-03 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2018-5453baa4af.nasl - Type: ACT_GATHER_INFO
2019-01-03 Name: The remote Fedora host is missing one or more security updates.
File: fedora_2018-5904d0794d.nasl - Type: ACT_GATHER_INFO
2019-01-03 Name: The remote Fedora host is missing a security update.
File: fedora_2018-5926c0ffc8.nasl - Type: ACT_GATHER_INFO