| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Microsoft ODBC Driver for SQL Server Remote Code Execution Vulnerability |
| Microsoft SQL Server Integration Service (VS extension) Remote Code Execution Vulnerability |
| Microsoft SQL Server Remote Code Execution Vulnerability |
| Visual Studio Code Elevation of Privilege Vulnerability |
| Visual Studio Code Information Disclosure Vulnerability |
| Microsoft Office Remote Code Execution Vulnerability |
| Dell Command Update, Dell Update and Alienware Update versions prior to 4.6.0 contains a Local Privilege Escalation Vulnerability in the custom catalog configuration. A local malicious user may potentially exploit this vulnerability in order to elevate their privileges. |
| Kerberos AppContainer Security Feature Bypass Vulnerability |
| HtmlUnit NekoHtml Parser before 2.61.0 suffers from a denial of service vulnerability. Crafted input associated with the parsing of Processing Instruction (PI) data leads to heap memory consumption. This is similar to CVE-2022-28366 but affects a much later version of the product. |
| Microsoft SQL Server Remote Code Execution Vulnerability |
| HEVC Video Extensions Remote Code Execution Vulnerability |
| Windows Kerberos Elevation of Privilege Vulnerability |
| HEVC Video Extensions Remote Code Execution Vulnerability |
| ASP.NET Core and Visual Studio Elevation of Privilege Vulnerability |
| ASP.NET Core and Visual Studio Information Disclosure Vulnerability |
| Visual Studio Code Remote Code Execution Vulnerability |
| An elevation of privilege vulnerability exists when the MpSigStub.exe for Defender allows file deletion in arbitrary locations.To exploit the vulnerability, an attacker would first have to log on to the system, aka 'Microsoft Defender Elevation of Privilege Vulnerability'. |
| In the Linux kernel, the following vulnerability has been resolved:
ip6: vti: Use ip6_tnl.net in vti6_changelink().
ip netns add ns1
ip netns add ns2
ip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7
ip -n ns1 link set vti6_test netns ns2
ip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9
ip netns del ns2
ip netns del ns1
[ 132.495484] ------------[ cut here ]------------
[ 132.497609] kernel BUG at net/core/dev.c:12376!
Commit 61220ab34948 ("vti6: Enable namespace changing") dropped
NETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then
move through IFLA_NET_NS_FD. After the move dev_net(dev) points
at the new netns while t->net stays at the creation netns.
vti6_changelink() and vti6_update() still use dev_net(dev) and
dev_net(t->dev). They unlink from one per netns hash and relink
into another. The creation netns is left with a stale entry.
cleanup_net() of that netns later walks freed memory.
Reachable from an unprivileged user namespace (unshare --user
--map-root-user --net). Cross tenant scope on container hosts. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers
Properly validate the count passed from a device when calling
svdm_consume_identity() or svdm_consume_identity_sop_prime() as the
device-controlled value could index off of the static arrays, which
could leak data. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes()
svdm_consume_modes() checks pmdata->altmodes against the array size once
before the loop over the count, but forgot to check the bound at every
point in the loop.
In the well-behaved SVDM discovery flow this is harmless because each of
at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX
modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX]. But the
CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming
ACK with any request the port actually sent. Once port->partner is set,
an unsolicited Discover Modes ACK is consumed unconditionally. A broken
or malicious port partner can therefore drive altmodes to
ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra
Discover Modes ACK with seven VDOs. Because the pre-loop check passes,
the loop could then writes up to five entries past altmode_desc[]. For
mode_data_prime the next field in struct tcpm_port is the
partner_altmode[] pointer array, which then receives partner-chosen
SVID/VDO bytes.
Move the bound check inside the loop so the array can never be indexed
past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner
supplies or how the function was reached. |
