On 2022-12-13 16:02, Stefan Hajnoczi wrote:
On Mon, Dec 12, 2022 at 05:09:47PM -0500, Jon Maloy wrote:
We add three new configuration flags, LIBCACARD, USB_SMARTCARD_PASSTHRU
and USB_SMARTCARD_EMULATED in order to improve configurability of these
functionalities.
Signed-off-by: Jon Maloy
We add two new configuration flags, USB_SMARTCARD_PASSTHRU and
USB_SMARTCARD_EMULATED in order to improve configurability of these
functionalities.
Signed-off-by: Jon Maloy
---
hw/usb/Kconfig | 12
hw/usb/meson.build | 4 ++--
2 files changed, 14 insertions(+), 2 deletions
We add a new configuration flag, LIBCACARD, indicating availability of the
libcacard code for building. This way, we can eliminate the explicit test
for cacard.found() when configuring
USB_SMARTCARD_EMULATED/USB_SMARTCARD_PASSTHRU
in hw/usb/meson.build.
Signed-off-by: Jon Maloy
We add three new configuration flags, LIBCACARD, USB_SMARTCARD_PASSTHRU
and USB_SMARTCARD_EMULATED in order to improve configurability of these
functionalities.
Signed-off-by: Jon Maloy
---
v2: Added a LIBACARD flag, plus reversed 'select' clauses, as suggested
by Paolo Bonzin
Please ignore this one. Sent to the wrong list.
///jon
On 11/24/22 21:32, Jon Maloy wrote:
Fixes: CVE-2019-14560
GetEfiGlobalVariable2() is used in some instances when looking up the
SecureBoot UEFI variable. The API can fail in certain circumstances,
for example, if AllocatePool() fails or
but that one was for some reason never posted to the edk2-devel
list. We now make a new attempt to get it reviewed and applied.
Signed-off-by: Jon Maloy
---
.../DxeImageVerificationLib.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git
We add two new configuration flags, USB_SMARTCARD_PASSTHRU and
USB_SMARTCARD_EMULATED in order to improve configurability
of these two functionalities.
Signed-off-by: Jon Maloy
---
hw/usb/Kconfig | 12
hw/usb/meson.build | 4 ++--
2 files changed, 14 insertions(+), 2 deletions
On 5/3/22 05:59, Kevin Wolf wrote:
Am 23.03.2022 um 03:25 hat John Snow geschrieben:
On Fri, Mar 18, 2022 at 2:50 PM Thomas Huth wrote:
On 10/03/2022 18.53, Jon Maloy wrote:
On 3/10/22 12:14, Thomas Huth wrote:
On 06/02/2022 20.19, Jon Maloy wrote:
Trying again with correct email
On 3/10/22 12:14, Thomas Huth wrote:
On 06/02/2022 20.19, Jon Maloy wrote:
Trying again with correct email address.
///jon
On 2/6/22 14:15, Jon Maloy wrote:
On 1/27/22 15:14, Jon Maloy wrote:
On 11/18/21 06:57, Philippe Mathieu-Daudé wrote:
Trivial fix for CVE-2021-3507.
Philippe
Trying again with correct email address.
///jon
On 2/6/22 14:15, Jon Maloy wrote:
On 1/27/22 15:14, Jon Maloy wrote:
On 11/18/21 06:57, Philippe Mathieu-Daudé wrote:
Trivial fix for CVE-2021-3507.
Philippe Mathieu-Daudé (2):
hw/block/fdc: Prevent end-of-track overrun (CVE-2021-3507
On 1/27/22 15:14, Jon Maloy wrote:
On 11/18/21 06:57, Philippe Mathieu-Daudé wrote:
Trivial fix for CVE-2021-3507.
Philippe Mathieu-Daudé (2):
hw/block/fdc: Prevent end-of-track overrun (CVE-2021-3507)
tests/qtest/fdc-test: Add a regression test for CVE-2021-3507
hw/block/fdc.c
-test.c | 20
2 files changed, 28 insertions(+)
Series
Acked-by: Jon Maloy
On 1/13/22 20:33, Jon Maloy wrote:
The function fdctrl_start_transfer() calculates the dma data length
wrongly when certain boundary conditions are fulfilled. We have
noticed that the if ((fdctrl->fifo[5] - fdctrl->fifo[6]) > 1) we get
a dma length that will be interpreted as negati
This fix is intended to address CVE-2021-3507.
Signed-off-by: Jon Maloy
---
hw/block/fdc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index 21d18ac2e3..80a1f1750a 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -1532,6 +1532,11 @@ st
This was the one I received.
///jon
On 12/16/21 14:01, Alexander Bulekov wrote:
On 211216 1935, Philippe Mathieu-Daudé wrote:
On 12/16/21 16:51, Jon Maloy wrote:
On 12/16/21 04:36, Philippe Mathieu-Daudé wrote:
Hi Jon,
On 10/21/21 18:10, Jon Maloy wrote:
The fact that the MMIO handler is
On 12/16/21 04:36, Philippe Mathieu-Daudé wrote:
Hi Jon,
On 10/21/21 18:10, Jon Maloy wrote:
The fact that the MMIO handler is not re-entrant causes an infinite
loop under certain conditions:
Guest write to TDT -> Loopback -> RX (DMA to TDT) -> TX
We now eliminate the effec
e is busy. This
will cause any entering new call to return early instead of interfering
with the ongoing work, and eliminates any risk of looping.
This is intended to address CVE-2021-20257.
Signed-off-by: Jon Maloy
---
hw/net/e1000.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/
31 libslirp]$
I updated from meson 0.52.0 to 0.55.3, but the result is exactly the same.
I commented out "main()" in fuzz-main.c just to check, but that is not
the issue of course.
To me it looks like the sanity checker is trying to link to
libclang_rt.fuzzer-x86_64.a twice, and at the same time is incapable of
finding LLVMFuzzerTestOneInput() which clearly is there.
Does anybody have any ideas about this?
BR
///Jon Maloy
18 matches
Mail list logo