Total
150 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2018-14599 | 5 Canonical, Debian, Fedoraproject and 2 more | 7 Ubuntu Linux, Debian Linux, Fedora and 4 more | 2024-11-21 | 7.5 HIGH | 9.8 CRITICAL |
| An issue was discovered in libX11 through 1.6.5. The function XListExtensions in ListExt.c is vulnerable to an off-by-one error caused by malicious server responses, leading to DoS or possibly unspecified other impact. | |||||
| CVE-2017-2618 | 3 Debian, Linux, Redhat | 8 Debian Linux, Linux Kernel, Enterprise Linux and 5 more | 2024-11-21 | 4.9 MEDIUM | 5.5 MEDIUM |
| A flaw was found in the Linux kernel's handling of clearing SELinux attributes on /proc/pid/attr files before 4.9.10. An empty (null) write to this file can crash the system by causing the system to attempt to access unmapped kernel memory. | |||||
| CVE-2017-1000416 | 1 Axtls Project | 1 Axtls | 2024-11-21 | 5.0 MEDIUM | 5.3 MEDIUM |
| axTLS version 1.5.3 has a coding error in the ASN.1 parser resulting in the year (19)50 of UTCTime being misinterpreted as 2050. | |||||
| CVE-2015-0841 | 1 Monopd Project | 1 Monopd | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| Off-by-one error in the readBuf function in listener.cpp in libcapsinetwork and monopd before 0.9.8, allows remote attackers to cause a denial of service (crash) via a long line. | |||||
| CVE-2014-8182 | 2 Debian, Openldap | 2 Debian Linux, Openldap | 2024-11-21 | 4.3 MEDIUM | 7.5 HIGH |
| An off-by-one error leading to a crash was discovered in openldap 2.4 when processing DNS SRV messages. If slapd was configured to use the dnssrv backend, an attacker could crash the service with crafted DNS responses. | |||||
| CVE-2010-5331 | 1 Linux | 1 Linux Kernel | 2024-11-21 | 4.6 MEDIUM | 7.8 HIGH |
| In the Linux kernel before 2.6.34, a range check issue in drivers/gpu/drm/radeon/atombios.c could cause an off by one (buffer overflow) problem. NOTE: At least one Linux maintainer believes that this CVE is incorrectly assigned and should be rejected because the value is hard coded and are not user-controllable where it is used | |||||
| CVE-2024-49880 | 1 Linux | 1 Linux Kernel | 2024-10-25 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ] | |||||
| CVE-2024-49862 | 1 Linux | 1 Linux Kernel | 2024-10-23 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access. | |||||
| CVE-2024-43852 | 1 Linux | 1 Linux Kernel | 2024-08-20 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: hwmon: (ltc2991) re-order conditions to fix off by one bug LTC2991_T_INT_CH_NR is 4. The st->temp_en[] array has LTC2991_MAX_CHANNEL (4) elements. Thus if "channel" is equal to LTC2991_T_INT_CH_NR then we have read one element beyond the end of the array. Flip the conditions around so that we check if "channel" is valid before using it as an array index. | |||||
| CVE-2024-36136 | 1 Ivanti | 1 Avalanche | 2024-08-15 | N/A | 7.5 HIGH |
| An off-by-one error in WLInfoRailService in Ivanti Avalanche 6.3.1 allows a remote unauthenticated attacker to crash the service, resulting in a DoS. | |||||