| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Incorrect default permissions in some onboard video driver software before version 1.14 for Intel(R) Server Boards based on Intel(R) 62X Chipset may allow an authenticated user to potentially enable escalation of privilege via local access. |
| Process Explorer before 17.04 allows attackers to make it functionally unavailable (a denial of service for analysis) by renaming an executable file to a new extensionless 255-character name and launching it with NtCreateUserProcess. This can occur through an issue in wcscat_s error handling. |
| Untrusted pointer dereference in UEFI firmware for some Intel(R) reference processors may allow a privileged user to potentially enable escalation of privilege via local access. |
| Improper access control in some Intel(R) CST before version 2.1.10300 may allow an authenticated user to potentially enable denial of service via local access. |
| Incorrect calculation in microcode keying mechanism for some Intel(R) Xeon(R) D Processors with Intel(R) SGX may allow a privileged user to potentially enable information disclosure via local access. |
| Improper access control in UEFI firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access. |
| An issue was discovered in Malwarebytes before 4.6.14.326 and before 5.1.5.116 (and Nebula 2020-10-21 and later). There is a Race condition that leads to code execution because of a lack of locks between file verification and execution. |
| An issue was discovered in Malwarebytes before 4.6.14.326 and before 5.1.5.116 (and Nebula 2020-10-21 and later). Out-of-bound reads in strings detection utilities lead to system crashes. |
| An issue was discovered in Malwarebytes 4.6.14.326 and before and 5.1.5.116 and before (and Nebula 2020-10-21 and later). An Out of bounds read in several disassembling utilities causes stability issues and denial of service. |
| Improper input validation in some Intel(R) CBI software before version 1.1.0 may allow an authenticated user to potentially enable denial of service via local access. |
| Incorrect default permissions for some Intel(R) Connectivity Performance Suite software installers before version 2.0 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| Uncontrolled search path in Intel(R) Graphics Command Center Service bundled in some Intel(R) Graphics Windows DCH driver software before versions 31.0.101.3790/31.0.101.2114 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| Improper conditions check in some Intel(R) Processors with Intel(R) SGX may allow a privileged user to potentially enable information disclosure via local access. |
| A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-7 LTE (All versions < V3.5.20), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.5.20), SIMATIC HMI Comfort Panels (incl. SIPLUS variants) (All versions), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMATIC WinCC Runtime Advanced (All versions), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.4.8), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.4.8). The web server of the affected devices do not properly handle the shutdown or reboot request, which could lead to the clean up of certain resources.
This could allow a remote attacker with elevated privileges to cause a denial of service condition in the system. |
| In the Linux kernel, the following vulnerability has been resolved:
rapidio: rio: fix possible name leak in rio_register_mport()
If device_register() returns error, the name allocated by dev_set_name()
need be freed. It should use put_device() to give up the reference in the
error path, so that the name can be freed in kobject_cleanup(), and
list_del() is called to delete the port from rio_mports. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: alcor: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and calling mmc_free_host() in the
error path. |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix the error length of VALIDATE_NEGOTIATE_INFO message
Commit d5c7076b772a ("smb3: add smb3.1.1 to default dialect list")
extend the dialects from 3 to 4, but forget to decrease the extended
length when specific the dialect, then the message length is larger
than expected.
This maybe leak some info through network because not initialize the
message body.
After apply this patch, the VALIDATE_NEGOTIATE_INFO message length is
reduced from 28 bytes to 26 bytes. |
| In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix memleak in alloc_ns()
After changes in commit a1bd627b46d1 ("apparmor: share profile name on
replacement"), the hname member of struct aa_policy is not valid slab
object, but a subset of that, it can not be freed by kfree_sensitive(),
use aa_policy_destroy() to fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
NFSD: Finish converting the NFSv2 GETACL result encoder
The xdr_stream conversion inadvertently left some code that set the
page_len of the send buffer. The XDR stream encoders should handle
this automatically now.
This oversight adds garbage past the end of the Reply message.
Clients typically ignore the garbage, but NFSD does not need to send
it, as it leaks stale memory contents onto the wire. |
| In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix shift-out-of-bounds due to too large exponent of block size
If field s_log_block_size of superblock data is corrupted and too large,
init_nilfs() and load_nilfs() still can trigger a shift-out-of-bounds
warning followed by a kernel panic (if panic_on_warn is set):
shift exponent 38973 is too large for 32-bit type 'int'
Call Trace:
<TASK>
dump_stack_lvl+0xcd/0x134
ubsan_epilogue+0xb/0x50
__ubsan_handle_shift_out_of_bounds.cold.12+0x17b/0x1f5
init_nilfs.cold.11+0x18/0x1d [nilfs2]
nilfs_mount+0x9b5/0x12b0 [nilfs2]
...
This fixes the issue by adding and using a new helper function for getting
block size with sanity check. |
