A vulnerability in the Linux kernel's EFI/CPER error handling was fixed. The flaw involved improper bounds checking in cper_print_fw_err(), which could cause underflow and lead to dumping large memory regions, potentially causing system instability or data disclosure. The issue has been addressed by adding proper length checks before memory dumps.
In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok <ok>| ok ok ok <x> \\ snd_nxt "x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).
CVE-2026-43201 is a vulnerability in the Linux kernel's APEI/GHES ARM processor error handling code. It occurs when the BIOS generates a very small or incomplete ARM Processor Error record, causing the kernel to dereference memory beyond the allocated bounds. This can lead to kernel OOPS (crash) conditions. The issue has been fixed by adding checks to prevent out-of-bounds memory access when processing GHESv2 records.
A use-after-free vulnerability was identified and resolved in the Linux kernel's FarSync T-series card driver (net: wan: farsync). The issue occurs when the device is detached and the associated data structure is freed while tasklets accessing it are still running or pending, leading to potential memory corruption. This flaw was detected by Kernel Address Sanitizer (KASAN) and affects specific Linux Azure kernel versions. A patch addressing this vulnerability is available.
A vulnerability in the Linux kernel's EFI/CPER handling for ARM processor error records allowed the kernel to trust an excessively large section_length value, causing it to dump data beyond the intended buffer. This could lead to denial of service due to excessive memory usage. The issue has been fixed by adding logic to validate the section_length against the buffer size and ERR_INFO_NUM. Multiple Linux kernel versions are affected, and a patch is available.
A vulnerability in the Linux kernel's APEI/GHES subsystem could cause a kernel OOPS due to improper handling of CPER record sizes. The flaw arises when firmware provides a CPER record size larger than the allocated memory, leading to a potential kernel paging fault. This issue has been fixed by ensuring the actual allocated area is considered when validating CPER length.
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix 22000 series SMEM parsing If the firmware were to report three LMACs (which doesn't exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is an overrun of the array. Reject such and use IWL_FW_CHECK instead of WARN_ON in this function.
In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl When page reassignment was added to af_alg_pull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary. Add the check to the reassignment so that this does not happen. Also update the comment which still refers to the obsolete offset argument.
CVE-2026-43114 is a critical vulnerability in the Linux kernel's netfilter component affecting the nft_set_pipapo_avx2 AVX2 matching functions. The flaw causes incorrect matching behavior when reloading a pipapo set with an 'ipv4 . port' key, leading to erroneous identification of non-matching entries as duplicates. This can result in data integrity issues and unexpected network filtering behavior. The issue is fixed in later kernel versions after 5.7. No known exploits are reported in the wild.
A vulnerability in QEMU's hardware display component related to virgl resources can cause accidental autofreeing of existing resources. This issue affects multiple specific Ubuntu package versions of QEMU. The vulnerability has a medium severity rating and no known exploits in the wild have been reported.
ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Libmodsecurity is one component of the ModSecurity v3 project. A segmentation fault occurs when a rule using the t:hexDecode transformation inspects a query string parameter containing a single character. An attacker can exploit this to crash worker processes, causing a denial of service. Service resumes once the attack stops as worker processes recover from the segfault. All versions before 3.0.15 of libModSecurity3 are affected. This has been patched in version 3.0.15.
CVE-2026-43063 is a high severity use-after-free vulnerability in the Linux kernel's XFS filesystem code. It occurs because the function xlog_recovery_iget* may return an error without setting a valid pointer, leading to a dangling pointer dereference when irele is called. This flaw has been fixed in specific Linux kernel commits.
I just got an email from SSL.com last night, they are rotating &#;x26;#;xc2;&#;x26;#;xa0;out their root certificate today (May 5,2026). &#;x26;#;xc2;&#;x26;#;xa0;This is normal, business as usual stuff for a CA, but certificates get used for all kinds of things, and sometimes they aren&#;x26;#;39;t used like they should be, so sometimes hiccups happen.
CVE-2026-7785 is an OS command injection vulnerability in the quick_capture function of the pyshark_mcp.py file within the A-G-U-P-T-A wireshark-mcp project. This flaw allows remote attackers to execute arbitrary OS commands due to improper input handling. The vulnerability has a CVSS 4.0 score of 6.9, indicating medium severity. The project uses a rolling release model, and no specific patched versions or vendor response have been provided yet. Exploit code has been publicly released, but no known active exploitation in the wild has been confirmed.
A stack overflow vulnerability exists in the WebCam Server Login functionality of GeoVision GV-VMS V20 20.0.2. A specially crafted HTTP request can lead to an arbitrary code execution. An attacker can make an unauthenticated HTTP request to trigger this vulnerability.
#### Stack-overflow via unconstrained sscanf
The call to `sscanf` at [1] to split the `Buffer` variable into the `username` and `password` variables doesn't limit the size of the extracted content to match the destination buffers' sizes. In this case, if either the username or password decoded from the authorization string exceeds `40` characters (the size the stack variables `username` and `password`) then a stack overflow will occur.
The data is controlled by an attacker, but sronger constraints (e.g.no null bytes) may make exploitation harder. A successful attack could lead to full code execution as SYSTEM on the machine running the service.