Summary
| Detail | |||
|---|---|---|---|
| Vendor | Linux | First view | 2014-02-28 |
| Product | Linux Kernel | Last view | 2024-04-28 |
| Version | 4.9.151 | 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
| Date | Alert | Description | |
|---|---|---|---|
| 7.8 | 2024-04-28 | CVE-2022-48662 | In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Really move i915_gem_context.link under ref protection i915_perf assumes that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration. However, this requires that we do not remove the context from the list until after we drop the final reference and release the struct. If, as currently, we remove the context from the list during context_close(), the link.next pointer may be poisoned while we are holding the context reference and cause a GPF: [ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff [ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180 [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915] [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202 [ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000 [ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68 [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc [ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860 [ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc [ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000 [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0 [ 4070.575029] Call Trace: [ 4070.575033] |
| 5.5 | 2024-04-28 | CVE-2022-48661 | In the Linux kernel, the following vulnerability has been resolved: gpio: mockup: Fix potential resource leakage when register a chip If creation of software node fails, the locally allocated string array is left unfreed. Free it on error path. |
| 5.5 | 2024-04-28 | CVE-2022-48660 | In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully When running gpio test on nxp-ls1028 platform with below command gpiomon --num-events=3 --rising-edge gpiochip1 25 There will be a warning trace as below: Call trace: free_irq+0x204/0x360 lineevent_free+0x64/0x70 gpio_ioctl+0x598/0x6a0 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x5c/0x130 ...... el0t_64_sync+0x1a0/0x1a4 The reason of this issue is that calling request_threaded_irq() function failed, and then lineevent_free() is invoked to release the resource. Since the lineevent_state::irq was already set, so the subsequent invocation of free_irq() would trigger the above warning call trace. To fix this issue, set the lineevent_state::irq after the IRQ register successfully. |
| 5.5 | 2024-04-28 | CVE-2022-48659 | In the Linux kernel, the following vulnerability has been resolved: mm/slub: fix to return errno if kmalloc() fails In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to out-of-memory, if it fails, return errno correctly rather than triggering panic via BUG_ON(); kernel BUG at mm/slub.c:5893! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: |
| 7.8 | 2024-04-28 | CVE-2022-48658 | In the Linux kernel, the following vulnerability has been resolved: mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context. Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context") moved all flush_cpu_slab() invocations to the global workqueue to avoid a problem related with deactivate_slab()/__free_slab() being called from an IRQ context on PREEMPT_RT kernels. When the flush_all_cpu_locked() function is called from a task context it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up flushing the global workqueue, this will cause a dependency issue. workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] Fix this bug by creating a workqueue for the flush operation with the WQ_MEM_RECLAIM bit set. |
| 7.8 | 2024-04-28 | CVE-2022-48655 | In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses. |
| 7.8 | 2024-04-17 | CVE-2024-26913 | In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dcn35 8k30 Underflow/Corruption Issue [why] odm calculation is missing for pipe split policy determination and cause Underflow/Corruption issue. [how] Add the odm calculation. |
| 5.5 | 2024-04-17 | CVE-2024-26912 | In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix several DMA buffer leaks Nouveau manages GSP-RM DMA buffers with nvkm_gsp_mem objects. Several of these buffers are never dealloced. Some of them can be deallocated right after GSP-RM is initialized, but the rest need to stay until the driver unloads. Also futher bullet-proof these objects by poisoning the buffer and clearing the nvkm_gsp_mem object when it is deallocated. Poisoning the buffer should trigger an error (or crash) from GSP-RM if it tries to access the buffer after we've deallocated it, because we were wrong about when it is safe to deallocate. Finally, change the mem->size field to a size_t because that's the same type that dma_alloc_coherent expects. |
| 3.3 | 2024-04-17 | CVE-2024-26911 | In the Linux kernel, the following vulnerability has been resolved: drm/buddy: Fix alloc_range() error handling code Few users have observed display corruption when they boot the machine to KDE Plasma or playing games. We have root caused the problem that whenever alloc_range() couldn't find the required memory blocks the function was returning SUCCESS in some of the corner cases. The right approach would be if the total allocated size is less than the required size, the function should return -ENOSPC. |
| 4.7 | 2024-04-17 | CVE-2024-26910 | In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait. Therefore the destroy functions are split into two: cancelling garbage collectors safely at executing the command received by netlink and moving the remaining part only into the rcu callback. |
| 5.5 | 2024-04-17 | CVE-2024-26909 | In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free A recent DRM series purporting to simplify support for "transparent bridges" and handling of probe deferrals ironically exposed a use-after-free issue on pmic_glink_altmode probe deferral. This has manifested itself as the display subsystem occasionally failing to initialise and NULL-pointer dereferences during boot of machines like the Lenovo ThinkPad X13s. Specifically, the dp-hpd bridge is currently registered before all resources have been acquired which means that it can also be deregistered on probe deferrals. In the meantime there is a race window where the new aux bridge driver (or PHY driver previously) may have looked up the dp-hpd bridge and stored a (non-reference-counted) pointer to the bridge which is about to be deallocated. When the display controller is later initialised, this triggers a use-after-free when attaching the bridges: dp -> aux -> dp-hpd (freed) which may, for example, result in the freed bridge failing to attach: [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16 or a NULL-pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 The DRM bridge implementation is clearly fragile and implicitly built on the assumption that bridges may never go away. In this case, the fix is to move the bridge registration in the pmic_glink_altmode driver to after all resources have been looked up. Incidentally, with the new dp-hpd bridge implementation, which registers child devices, this is also a requirement due to a long-standing issue in driver core that can otherwise lead to a probe deferral loop (see commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")). [DB: slightly fixed commit message by adding the word 'commit'] |
| 7.8 | 2024-04-17 | CVE-2024-26907 | In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ |
| 5.5 | 2024-04-17 | CVE-2024-26904 | In the Linux kernel, the following vulnerability has been resolved: btrfs: fix data race at btrfs_use_block_rsv() when accessing block reserve At btrfs_use_block_rsv() we read the size of a block reserve without locking its spinlock, which makes KCSAN complain because the size of a block reserve is always updated while holding its spinlock. The report from KCSAN is the following: [653.313148] BUG: KCSAN: data-race in btrfs_update_delayed_refs_rsv [btrfs] / btrfs_use_block_rsv [btrfs] [653.314755] read to 0x000000017f5871b8 of 8 bytes by task 7519 on cpu 0: [653.323887] write to 0x000000017f5871b8 of 8 bytes by task 576 on cpu 3: So add a helper to get the size of a block reserve while holding the lock. Reading the field while holding the lock instead of using the data_race() annotation is used in order to prevent load tearing. |
| 5.5 | 2024-04-17 | CVE-2024-26903 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected. 3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcomm_check_security function. However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` had already been released, and when the function executed `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically when accessing `conn->hcon`, a null-ptr-deref error occurred. To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling rfcomm_recv_frame in rfcomm_process_rx. |
| 5.5 | 2024-04-17 | CVE-2024-26902 | In the Linux kernel, the following vulnerability has been resolved: perf: RISCV: Fix panic on pmu overflow handler (1 << idx) of int is not desired when setting bits in unsigned long overflowed_ctrs, use BIT() instead. This panic happens when running 'perf record -e branches' on sophgo sg2042. [ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [ 273.320851] Oops [#1] [ 273.323179] Modules linked in: [ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9 [ 273.332521] Hardware name: Sophgo Mango (DT) [ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e [ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0 [ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978 [ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70 [ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000 [ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015 [ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a [ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0 [ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210 [ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098 [ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca [ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8 [ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d [ 273.434512] [ |
| 5.5 | 2024-04-17 | CVE-2024-26901 | In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 Uninit was created at: Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. |
| 5.5 | 2024-04-17 | CVE-2024-26900 | In the Linux kernel, the following vulnerability has been resolved: md: fix kmemleak of rdev->serial If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs. unreferenced object 0xffff88815a350000 (size 49152): |
| 5.5 | 2024-04-17 | CVE-2024-26899 | In the Linux kernel, the following vulnerability has been resolved: block: fix deadlock between bd_link_disk_holder and partition scan 'open_mutex' of gendisk is used to protect open/close block devices. But in bd_link_disk_holder(), it is used to protect the creation of symlink between holding disk and slave bdev, which introduces some issues. When bd_link_disk_holder() is called, the driver is usually in the process of initialization/modification and may suspend submitting io. At this time, any io hold 'open_mutex', such as scanning partitions, can cause deadlocks. For example, in raid: T1 T2 bdev_open_by_dev T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume mddev, but T2 waits for open_mutex held by T1. Deadlock occurs. Fix it by introducing a local mutex 'blk_holder_mutex' to replace 'open_mutex'. |
| 7.8 | 2024-04-17 | CVE-2024-26898 | In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts This patch is against CVE-2023-6270. The description of cve is: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial code is finished. But the net_device ifp will still be used in later tx()->dev_queue_xmit() in kthread. Which means that the dev_put(ifp) should NOT be called in the success path of skb initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into use-after-free because the net_device is freed. This patch removed the dev_put(ifp) in the success path in aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx(). |
| 7.8 | 2024-04-17 | CVE-2024-26885 | In the Linux kernel, the following vulnerability has been resolved: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation. |
| 7.8 | 2024-04-17 | CVE-2024-26884 | In the Linux kernel, the following vulnerability has been resolved: bpf: Fix hashtab overflow check on 32-bit arches The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup. |
| 7.8 | 2024-04-17 | CVE-2024-26883 | In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check on 32-bit arches The stackmap code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. The commit in the fixes tag actually attempted to fix this, but the fix did not account for the UB, so the fix only works on CPUs where an overflow does result in a neat truncation to zero, which is not guaranteed. Checking the value before rounding does not have this problem. |
| 7.8 | 2024-04-17 | CVE-2024-26882 | In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() Apply the same fix than ones found in : 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. syzbot reported: BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] Uninit was created at: |
| 5.5 | 2024-04-17 | CVE-2024-26881 | In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is received on HIP08 devices The HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL, but the hardware can receive 1588 messages, and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the access of hdev->ptp->flags will cause a kernel crash: [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge] [ 5889.279101] sp : ffff800012c3bc50 [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000 [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480 [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000 [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000 [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080 [ 5889.378857] Call trace: [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3] [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3] [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3] [ 5889.411084] napi_poll+0xcc/0x264 [ 5889.415329] net_rx_action+0xd4/0x21c [ 5889.419911] __do_softirq+0x130/0x358 [ 5889.424484] irq_exit+0x134/0x154 [ 5889.428700] __handle_domain_irq+0x88/0xf0 [ 5889.433684] gic_handle_irq+0x78/0x2c0 [ 5889.438319] el1_irq+0xb8/0x140 [ 5889.442354] arch_cpu_idle+0x18/0x40 [ 5889.446816] default_idle_call+0x5c/0x1c0 [ 5889.451714] cpuidle_idle_call+0x174/0x1b0 [ 5889.456692] do_idle+0xc8/0x160 [ 5889.460717] cpu_startup_entry+0x30/0xfc [ 5889.465523] secondary_start_kernel+0x158/0x1ec [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [ 5889.477950] SMP: stopping secondary CPUs [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95 [ 5890.522951] Starting crashdump kernel... |
| 4.7 | 2024-04-17 | CVE-2023-52645 | In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: fix race conditions with genpd If the power domains are registered first with genpd and *after that* the driver attempts to power them on in the probe sequence, then it is possible that a race condition occurs if genpd tries to power them on in the same time. The same is valid for powering them off before unregistering them from genpd. Attempt to fix race conditions by first removing the domains from genpd and *after that* powering down domains. Also first power up the domains and *after that* register them to genpd. |
CWE : Common Weakness Enumeration
| % | id | Name |
|---|---|---|
| 22% (314) | CWE-416 | Use After Free |
| 14% (196) | CWE-476 | NULL Pointer Dereference |
| 8% (116) | CWE-362 | Race Condition |
| 7% (110) | CWE-787 | Out-of-bounds Write |
| 6% (96) | CWE-401 | Failure to Release Memory Before Removing Last Reference ('Memory L... |
| 6% (96) | CWE-125 | Out-of-bounds Read |
| 4% (65) | CWE-119 | Failure to Constrain Operations within the Bounds of a Memory Buffer |
| 2% (38) | CWE-200 | Information Exposure |
| 2% (38) | CWE-190 | Integer Overflow or Wraparound |
| 1% (27) | CWE-667 | Insufficient Locking |
| 1% (27) | CWE-415 | Double Free |
| 1% (27) | CWE-20 | Improper Input Validation |
| 1% (18) | CWE-120 | Buffer Copy without Checking Size of Input ('Classic Buffer Overflo... |
| 0% (13) | CWE-400 | Uncontrolled Resource Consumption ('Resource Exhaustion') |
| 0% (12) | CWE-665 | Improper Initialization |
| 0% (11) | CWE-755 | Improper Handling of Exceptional Conditions |
| 0% (10) | CWE-772 | Missing Release of Resource after Effective Lifetime |
| 0% (9) | CWE-770 | Allocation of Resources Without Limits or Throttling |
| 0% (9) | CWE-369 | Divide By Zero |
| 0% (8) | CWE-668 | Exposure of Resource to Wrong Sphere |
| 0% (8) | CWE-404 | Improper Resource Shutdown or Release |
| 0% (8) | CWE-122 | Heap-based Buffer Overflow |
| 0% (7) | CWE-203 | Information Exposure Through Discrepancy |
| 0% (6) | CWE-763 | Release of Invalid Pointer or Reference |
| 0% (6) | CWE-754 | Improper Check for Unusual or Exceptional Conditions |
Snort® IPS/IDS
| 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-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 |
Nessus® Vulnerability Scanner
| 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 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 |
| 2019-01-03 | Name: The remote Fedora host is missing one or more security updates. File: fedora_2018-59e4747e0f.nasl - Type: ACT_GATHER_INFO |
