Summary
| Detail | |||
|---|---|---|---|
| Vendor | Linux | First view | 2014-02-28 |
| Product | Linux Kernel | Last view | 2024-02-27 |
| Version | 4.2.0 | 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.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 CPU: 0 PID: 947 Comm: ping Not tainted 5.12.0-rc6+ #418 The buggy address belongs to the page: Memory state around the buggy address: for IPv4 packets, sch_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() 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 |
| 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 |
| 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 |
| 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 [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: 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: 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() { 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): 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 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 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] [ |
| 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 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 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: |
CWE : Common Weakness Enumeration
| % | id | Name |
|---|---|---|
| 20% (328) | CWE-416 | Use After Free |
| 13% (205) | CWE-476 | NULL Pointer Dereference |
| 9% (145) | CWE-362 | Race Condition |
| 7% (113) | 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% (83) | CWE-119 | Failure to Constrain Operations within the Bounds of a Memory Buffer |
| 4% (66) | CWE-200 | Information Exposure |
| 2% (44) | CWE-190 | Integer Overflow or Wraparound |
| 2% (38) | CWE-20 | Improper Input Validation |
| 1% (31) | CWE-415 | Double Free |
| 1% (25) | CWE-667 | Insufficient Locking |
| 1% (18) | CWE-120 | Buffer Copy without Checking Size of Input ('Classic Buffer Overflo... |
| 1% (16) | CWE-400 | Uncontrolled Resource Consumption ('Resource Exhaustion') |
| 0% (14) | CWE-264 | Permissions, Privileges, and Access Controls |
| 0% (13) | CWE-399 | Resource Management Errors |
| 0% (12) | CWE-665 | Improper Initialization |
| 0% (11) | CWE-772 | Missing Release of Resource after Effective Lifetime |
| 0% (10) | CWE-369 | Divide By Zero |
| 0% (9) | CWE-770 | Allocation of Resources Without Limits or Throttling |
| 0% (9) | CWE-755 | Improper Handling of Exceptional Conditions |
| 0% (9) | CWE-284 | Access Control (Authorization) Issues |
| 0% (8) | CWE-668 | Exposure of Resource to Wrong Sphere |
| 0% (8) | CWE-269 | Improper Privilege Management |
| 0% (8) | CWE-122 | Heap-based Buffer Overflow |
SAINT Exploits
| Description | Link |
|---|---|
| Linux Dirty COW Local File Overwrite | More info here |
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-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
| 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 |
