Search
Search Results (17 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-72347 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 7.3 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_connmark: reject invalid shift parameters Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmark_tg_shift(). A shift_bits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shift_dir values are also accepted and silently fall back to the left-shift path. Reject invalid revision-2 shift parameters in connmark_tg_check() so malformed rules fail at installation time, before they can reach the packet path. | ||||
| CVE-2026-72450 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: xfrm: validate selector family and prefixlen during match syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set). Fix this by: - Rejecting mismatched families in xfrm_selector_match. - Returning false in addr4_match if prefixlen > 32. - Returning false in addr_match if prefixlen > 128 (prevents overflow). | ||||
| CVE-2026-74297 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix undefined shift of user RQ WQE size set_rq_size() computes the RQ WQE size as "1 << rq_wqe_shift" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior. Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values. | ||||
| CVE-2026-74544 | 1 Linux | 1 Linux Kernel | 2026-08-21 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: validate offshift to prevent shift-out-of-bounds u32_change() copies the user-provided tc_u32_sel.offshift (unsigned char, 0-255) into the kernel knode object without bounds validation. When a packet later hits u32_classify() with TC_U32_VAROFFSET set, it evaluates `ntohs(offmask & *data) >> offshift` where the left operand is a 16-bit value promoted to a 32-bit int. Any offshift >= 32 is undefined behavior per C11 6.5.7p3, triggerable by an unprivileged user via user/network namespaces. UBSAN: shift-out-of-bounds in net/sched/cls_u32.c:236:43 shift exponent 32 is too large for 32-bit type int Fix this by rejecting offshift >= 16 during filter creation in u32_change(). | ||||
| CVE-2026-72350 | 1 Linux | 1 Linux Kernel | 2026-08-17 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_u32: reject invalid shift counts u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation. Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path. | ||||
| CVE-2026-46101 | 1 Linux | 1 Linux Kernel | 2026-08-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path. | ||||
| CVE-2026-64006 | 1 Linux | 1 Linux Kernel | 2026-07-21 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix dst corruption in same register operation For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value. Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode: table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x66443322 0x00887766 ] [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3 [ immediate reg 1 0x44332211 0x88776655 ] [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ] [ cmp eq reg 1 0x55443322 0x00887766 ] [ counter pkts 21794 bytes 1917798 ] | ||||
| CVE-2026-31624 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: core: clamp report_size in s32ton() to avoid undefined shift s32ton() shifts by n-1 where n is the field's report_size, a value that comes directly from a HID device. The HID parser bounds report_size only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hid_output_field() or hid_set_field(). Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in hid_report_raw_event") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way. Fix this up by just clamping the max value of n, just like snto32() does. | ||||
| CVE-2026-31412 | 1 Linux | 1 Linux Kernel | 2026-05-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_mass_storage: Fix potential integer overflow in check_command_size_in_blocks() The `check_command_size_in_blocks()` function calculates the data size in bytes by left shifting `common->data_size_from_cmnd` by the block size (`common->curlun->blkbits`). However, it does not validate whether this shift operation will cause an integer overflow. Initially, the block size is set up in `fsg_lun_open()` , and the `common->data_size_from_cmnd` is set up in `do_scsi_command()`. During initialization, there is no integer overflow check for the interaction between two variables. So if a malicious USB host sends a SCSI READ or WRITE command requesting a large amount of data (`common->data_size_from_cmnd`), the left shift operation can wrap around. This results in a truncated data size, which can bypass boundary checks and potentially lead to memory corruption or out-of-bounds accesses. Fix this by using the check_shl_overflow() macro to safely perform the shift and catch any overflows. | ||||
| CVE-2026-4426 | 2 Libarchive, Redhat | 6 Libarchive, Enterprise Linux, Hardened Images and 3 more | 2026-05-03 | 6.5 Medium |
| A flaw was found in libarchive. An Undefined Behavior vulnerability exists in the zisofs decompression logic, caused by improper validation of a field (`pz_log2_bs`) read from ISO9660 Rock Ridge extensions. A remote attacker can exploit this by supplying a specially crafted ISO file. This can lead to incorrect memory allocation and potential application crashes, resulting in a denial-of-service (DoS) condition. | ||||
| CVE-2023-52810 | 1 Linux | 1 Linux Kernel | 2026-01-05 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Add check for negative db_l2nbperpage l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative. In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent. Syzbot reported this bug: UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative | ||||
| CVE-2016-9842 | 8 Apple, Canonical, Debian and 5 more | 22 Iphone Os, Mac Os X, Tvos and 19 more | 2025-12-04 | 8.8 High |
| The inflateMark function in inflate.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact via vectors involving left shifts of negative integers. | ||||
| CVE-2025-46152 | 2 Linuxfoundation, Pytorch | 2 Pytorch, Pytorch | 2025-10-03 | 5.3 Medium |
| In PyTorch before 2.7.0, bitwise_right_shift produces incorrect output for certain out-of-bounds values of the "other" argument. | ||||
| CVE-2024-56431 | 1 Xiph | 1 Theora | 2025-05-07 | 9.8 Critical |
| oc_huff_tree_unpack in huffdec.c in libtheora in Theora through 1.0 7180717 has an invalid negative left shift. NOTE: this is disputed by third parties because there is no evidence of a security impact, e.g., an application would not crash. | ||||
| CVE-2021-47263 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: gpio: wcd934x: Fix shift-out-of-bounds error bit-mask for pins 0 to 4 is BIT(0) to BIT(4) however we ended up with BIT(n - 1) which is not right, and this was caught by below usban check UBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14 | ||||
| CVE-2025-32029 | 2025-04-08 | N/A | ||
| ts-asn1-der is a collection of utility classes to encode ASN.1 data following DER rule. Incorrect number DER encoding can lead to denial on service for absolute values in the range 2**31 -- 2**32 - 1. The arithmetic in the numBitLen didn't take into account that values in this range could result in a negative result upon applying the >> operator, leading to an infinite loop. The issue is patched in version 1.0.4. If upgrading is not an option, the issue can be mitigated by validating inputs to Asn1Integer to ensure that they are not smaller than -2**31 + 1 and no larger than 2**31 - 1. | ||||
| CVE-2023-3161 | 3 Fedoraproject, Linux, Redhat | 5 Fedora, Linux Kernel, Enterprise Linux and 2 more | 2025-03-11 | 5.5 Medium |
| A flaw was found in the Framebuffer Console (fbcon) in the Linux Kernel. When providing font->width and font->height greater than 32 to fbcon_set_font, since there are no checks in place, a shift-out-of-bounds occurs leading to undefined behavior and possible denial of service. | ||||
Page 1 of 1.