CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
xgrammar is an open-source library for efficient, flexible, and portable structured generation. A grammar optimizer introduced in 0.1.23 processes large grammars (>100k characters) at very low rates, and can be used for DOS of model providers. This issue is fixed in version 0.1.24. |
Improper cleanup in AMD CPU microcode patch loading could allow an attacker with local administrator privilege to load malicious CPU microcode, potentially resulting in loss of integrity of x86 instruction execution. |
Improper removal of sensitive information before storage or transfer in AMD Crash Defender could allow an attacker to obtain kernel address information potentially resulting in loss of confidentiality. |
An out of bounds write in the Linux graphics driver could allow an attacker to overflow the buffer potentially resulting in loss of confidentiality, integrity, or availability. |
Improper input validation in the AMD Graphics Driver could allow an attacker to supply a specially crafted pointer, potentially leading to arbitrary writes or denial of service. |
Improper input validation in AMD Power Management Firmware (PMFW) could allow a privileged attacker from Guest VM to send arbitrary input data potentially causing a GPU Reset condition. |
Improper input validation in the GPU driver could allow an attacker to exploit a heap overflow potentially resulting in arbitrary code execution. |
Improper initialization of CPU cache memory could allow a privileged attacker with hypervisor access to overwrite SEV-SNP guest memory resulting in loss of data integrity. |
Missing authorization in AMD RomArmor could allow an attacker to bypass ROMArmor protections during system resume from a standby state, potentially resulting in a loss of confidentiality and integrity. |
Improper validation of an array index in the AND power Management Firmware could allow a privileged attacker to corrupt AGESA memory potentially leading to a loss of integrity. |
Improper restriction of operations in the IOMMU could allow a malicious hypervisor to access guest private memory resulting in loss of integrity. |
An out-of-bounds read in the ASP could allow a privileged attacker with access to a malicious bootloader to potentially read sensitive memory resulting in loss of confidentiality. |
Use of an uninitialized variable in the ASP could allow an attacker to access leftover data from a trusted execution environment (TEE) driver, potentially leading to loss of confidentiality. |
Improper isolation of shared resources on System-on-a-chip (SOC) could a privileged attacker to tamper with the contents of the PSP reserved DRAM region potentially resulting in loss of confidentiality and integrity. |
A security flaw has been discovered in itsourcecode POS Point of Sale System 1.0. This vulnerability affects unknown code of the file /inventory/main/vendors/datatables/unit_testing/templates/complex_header_2.php. Performing manipulation of the argument scripts results in cross site scripting. The attack may be initiated remotely. The exploit has been released to the public and may be exploited. |
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: Fix MAC comparison to be constant-time
To prevent timing attacks, MACs need to be compared in constant time.
Use the appropriate helper function for this. |
In the Linux kernel, the following vulnerability has been resolved:
comedi: pcl726: Prevent invalid irq number
The reproducer passed in an irq number(0x80008000) that was too large,
which triggered the oob.
Added an interrupt number check to prevent users from passing in an irq
number that was too large.
If `it->options[1]` is 31, then `1 << it->options[1]` is still invalid
because it shifts a 1-bit into the sign bit (which is UB in C).
Possible solutions include reducing the upper bound on the
`it->options[1]` value to 30 or lower, or using `1U << it->options[1]`.
The old code would just not attempt to request the IRQ if the
`options[1]` value were invalid. And it would still configure the
device without interrupts even if the call to `request_irq` returned an
error. So it would be better to combine this test with the test below. |
In the Linux kernel, the following vulnerability has been resolved:
net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization
Syzbot reported shift-out-of-bounds exception on MDIO bus initialization.
The PHY address should be masked to 5 bits (0-31). Without this
mask, invalid PHY addresses could be used, potentially causing issues
with MDIO bus operations.
Fix this by masking the PHY address with 0x1f (31 decimal) to ensure
it stays within the valid range. |
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid a NULL pointer dereference
[WHY]
Although unlikely drm_atomic_get_new_connector_state() or
drm_atomic_get_old_connector_state() can return NULL.
[HOW]
Check returns before dereference.
(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9) |
In the Linux kernel, the following vulnerability has been resolved:
comedi: Make insn_rw_emulate_bits() do insn->n samples
The `insn_rw_emulate_bits()` function is used as a default handler for
`INSN_READ` instructions for subdevices that have a handler for
`INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a default
handler for `INSN_WRITE` instructions for subdevices that have a handler
for `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the
`INSN_READ` or `INSN_WRITE` instruction handling with a constructed
`INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE`
instructions are supposed to be able read or write multiple samples,
indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currently
only handles a single sample. For `INSN_READ`, the comedi core will
copy `insn->n` samples back to user-space. (That triggered KASAN
kernel-infoleak errors when `insn->n` was greater than 1, but that is
being fixed more generally elsewhere in the comedi core.)
Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or return
an error, to conform to the general expectation for `INSN_READ` and
`INSN_WRITE` handlers. |