| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An integer overflow was addressed with improved input validation. This issue is fixed in Safari 26.6.1, iOS 26.6.1 and iPadOS 26.6.1, macOS Tahoe 26.6.2, tvOS 27, visionOS 27, watchOS 27. Processing maliciously crafted web content may lead to memory corruption. |
| An integer underflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. Connecting to a malicious SMB server may lead to unexpected system termination. |
| An integer overflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. Connecting to a malicious NFS server may cause unexpected system termination or corrupt kernel memory. |
| An integer overflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27. Processing a maliciously crafted file may lead to a denial-of-service or potentially disclose memory contents. |
| An integer overflow was addressed with improved input validation. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27, watchOS 27. Processing a maliciously crafted 3D model may lead to memory corruption. |
| An integer overflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An attacker in a privileged network position may be able to cause a denial-of-service. |
| An integer overflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to cause a denial of service. |
| A security vulnerability has been detected in SerenityOS up to 3d83e4509fd20d7438e1ae8470ffe668c136229c. Affected by this vulnerability is the function decode_bmp_pixel_data of the file Userland/Libraries/LibGfx/ImageFormats/BMPLoader.cpp of the component LibGfx. The manipulation of the argument height leads to integer overflow. The attack is possible to be carried out remotely. The attack's complexity is rated as high. The exploitation appears to be difficult. The exploit has been disclosed publicly and may be used. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. The identifier of the patch is 007041bb2dd6d140c9e707caddfb0a49ecf96469. Applying a patch is the recommended action to fix this issue. This was reproducible with a minimal 55-byte PoC via the standard image-decode fuzz target but evidence for an actual exploitable defect is thin. |
| A vulnerability exists in the proxy packet processing logic of the affected component where it improperly processes malformed or truncated input. An unauthenticated remote attacker could exploit this vulnerability by providing specially crafted input that triggers an integer overflow. Successful exploitation could result in a buffer overflow, potentially leading to remote code execution or denial-of-service. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_skbmod: fix length calculations and avoid invalid header warnings
syzbot reported a warning in skb_network_header_len() triggered
by tcf_skbmod_act():
!skb_transport_header_was_set(skb)
WARNING: CPU: 0 PID: 14949 at include/linux/skbuff.h:3243 skb_network_header_len include/linux/skbuff.h:3243 [inline]
WARNING: CPU: 0 PID: 14949 at net/sched/act_skbmod.c:55 tcf_skbmod_act+0xfe8/0x1810 net/sched/act_skbmod.c:55
There are a few issues in tcf_skbmod_act():
1. Calling skb_network_header_len() assumes skb->transport_header is set,
which is not guaranteed when tcf_skbmod_act() runs at TC ingress.
2. Unconditionally calling skb_mac_header_len() at the beginning of
tcf_skbmod_act() triggers a warning on L3 devices (e.g. TUN) where the
MAC header is unset, evaluating to an underflowed garbage length.
3. On TC ingress, skb->data points to the network header. Adding the MAC
header length to the IP header length causes skb_ensure_writable() to
request more bytes than the actual IP packet length, dropping valid
short packets (e.g. 28-byte UDP/IPv4 packets).
Fix these by:
- Using skb_network_offset(skb) + sizeof(struct iphdr/ipv6hdr) for
SKBMOD_F_ECN so that the required length is correctly calculated on
both ingress (offset == 0) and egress (offset == mac_len).
- Setting max_edit_len to ETH_HLEN for Ethernet header modifications
after validating ARPHRD_ETHER. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: sfq: clamp quantum to avoid signed overflow soft lockup
sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A
device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU
2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN
and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning
sfq_dequeue() under the qdisc lock.
Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The
lower bound also covers q->quantum == 0 (psched_mtu() returning 0),
which spins sfq_dequeue() identically. sfq_change() already rejects a
negative quantum, so only the init path was exposed.
Conditions to recreate the bug: a device whose MTU (plus
hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy
device with max_mtu == 0 accepting MTU 2147483634). Requires
CAP_NET_ADMIN in a user namespace. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq_pie: clamp default quantum to avoid signed overflow
fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without
clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0
accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which
overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(),
causing an infinite loop and soft lockup. Emulate fq_pie_policy which
is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20].
256 matches fq_codel's floor and is a sane minimum for a DRR quantum.
Conditions to recreate the bug: a device whose MTU (plus
hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy
device with max_mtu == 0 accepting MTU 2147483634). Requires
CAP_NET_ADMIN in a user namespace. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: fq: add overflow bounds to quantum and initial quantum
fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 *
psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy
with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return
0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit
arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill
loop adds 0 to f->credit (which stays <= 0) and goto begin loops
forever under the qdisc lock, creating a soft lockup.
Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product
cannot wrap, then cap the result at 1 << 20, matching the bound already
enforced on TCA_FQ_QUANTUM in fq_change().
Conditions to recreate the bug: a device whose MTU (plus
hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a
dummy device with max_mtu == 0 accepting MTU 2147483634). Requires
CAP_NET_ADMIN in a user namespace. |
| In the Linux kernel, the following vulnerability has been resolved:
ptp: netc: fix period truncation and potential divide-by-zero in PEROUT
The max_period bound in net_timer_enable_perout() was computed as:
max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;
which exceeds U32_MAX when integral_period > 0 (e.g. 0x100000002 for
the default 333333333 Hz clock). A period_ns that passes this check but
exceeds U32_MAX is then silently truncated when stored into the u32
struct netc_pp::period field.
A truncated value of zero can reach netc_timer_set_perout_alarm(), where
the local u32 period variable would also be 0, causing a divide-by-zero
in roundup_u64(delta, period) whenever the stime < min_time branch is
taken (which always happens for a start time of {0, 0}).
Additionally, netc_timer_enable_periodic_pulse() and
netc_timer_enable_fiper() both compute:
fiper = pp->period - integral_period;
A zero pp->period results in an unsigned wraparound to 0xFFFFFFFD,
mis-programming the FIPER hardware register.
Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER
(0xFFFFFFFF). This ensures that any period_ns passing the range check
fits in a u32 without truncation, so the stored value is always valid
and non-zero. The accepted range is reduced by integral_period ns
(typically only a few nanoseconds), which is negligible in practice. |
| FluidSynth is a software synthesizer based on the SoundFont 2 specifications. From 2.5.0 until 2.5.6, the native DLS parser validates articulation chunks using the unsigned expression cbsize + connblocks * 12 without first ensuring that the multiplication and addition fit in 32 bits. A crafted DLS file can supply a large connblocks value that wraps the expression and bypasses the chunk-size check, after which the parser performs approximately one billion 12-byte iterations beyond the chunk boundary. The excessive processing and invalid reads can cause denial of service. Builds with the CMake option enable-native-dls set to OFF do not expose the parser. This issue is fixed in version 2.5.6. |
| In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix integer overflow in ftp helper port/address parsing
ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16
(hport) and into unsigned char (p[]) without checking for overflow.
A crafted FTP PASV/EPSV response with an over-long port or address
octet wraps the value, so the helper configures the data connection
with a truncated port/address.
The netfilter conntrack FTP helper had the same defect, fixed in
commit 2b413fc689ba ("netfilter: nf_conntrack_ftp: avoid u16
overflows"). Apply the equivalent fix here: widen the port accumulator
to u32 and reject values above 65535, and reject address octets above
255. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix integer overflow of user QP buffer size
set_user_buf_size() computes the QP buffer size by left-shifting the
user-supplied rq.wqe_cnt and rq.wqe_shift values as signed integers.
A sufficiently large rq.wqe_cnt causes signed integer overflow, which
is undefined behavior, and yields a small or negative buf_size, causing
ib_umem_get() to map a buffer smaller than the hardware will actually
write into.
Replace the shifts and addition with check_shl_overflow() and
check_add_overflow(), rejecting invalid user inputs.
Moreover, guard the identical shift computing qp->sq.offset in
_create_user_qp() before set_user_buf_size() is reached. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: validate topology volume range before allocation
SOF treats the topology mixer min and max values as non-negative indices
into its volume table. It stores them in signed fields, allocates max + 1
entries through an int argument, and later indexes the table with the
stored range.
An inverted range is invalid, while a maximum at or above INT_MAX cannot
be represented safely after the increment or in the signed fields.
Validate the complete range before storing it or allocating the table. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: reject out-of-range evcn in mi_enum_attr()
In mi_enum_attr(), the start/end VCN validation for non-resident
attributes is:
if (svcn > evcn + 1) goto out;
When evcn is U64_MAX the "evcn + 1" expression wraps to 0 and any svcn
passes the check. For evcn values close to U64_MAX (but not equal to it)
the right-hand side is still a meaningless near-wrap upper bound, so a
malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass
mi_enum_attr() unrejected.
VCN (virtual cluster number) is a cluster index, so any valid evcn is
bounded by the volume's total cluster count, which ntfs3 holds in
sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller
of mi_enum_attr() runs). Reject evcn values that fall outside this range.
However, an empty non-resident attribute (no allocated clusters) is
legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via
attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel
must keep passing, so exclude evcn == U64_MAX from the range check. The
existing "svcn > evcn + 1" test still tolerates the sentinel ("0 > 0" is
false) and continues to require svcn == 0 for it, while the range check
rejects every other out-of-range evcn and thereby also defuses the
"evcn + 1" wraparound.
svcn does not need its own bound: once evcn < nbits, "svcn > evcn + 1"
implies svcn <= nbits.
[almaz.alexandrovich@paragon-software.com: fixed evcn check] |
| In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check block offset is not negative
If a negative offset is read off disk (for example the offset into the
decompressed fragment block), this will cause squashfs_copy_data() to
perform an out of bounds access.
Fix by checking if offset is negative, and returning 0. This matches
existing behaviour where an offset beyond the block returns 0 bytes
copied.
To trigger this out of bounds access requires a crafted Squashfs
filesystem and CAP_SYS_ADMIN to mount it. Unprivileged users will not be
able to mount such a filesystem, but once mounted, an unprivileged user
can trigger the out of bounds access by reading the crafted file with the
negative offset. |
