| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0003-allow-debian-flags-to-be-added.patch | Hard code in hardening options =================================================================== |
Colin Ian King <colin.i.king@gmail.com> | not-needed | |||
| 0001-alter-install-paths.patch | Workaround environment variable settings Add environment to be set by packaging =================================================================== |
Colin Ian King <colin.i.king@gmail.com> | not-needed | |||
| 0002-remove-build-and-install-of-examples.patch | Remove examples No need to install these, developers are encouraged to look at the code in the repository =================================================================== |
Colin Ian King <colin.i.king@gmail.com> | not-needed | |||
| 0004-lib-Fix-MBR-value-for-non-SNC-machines.patch | [PATCH] lib: Fix MBR value for non-SNC machines There is an issue in counting remote traffic for non-SNC machines, it is always 0. mapping: NUMA node0 CPU(s): 0-47,96-143 NUMA node1 CPU(s): 48-95,144-191 Let's generate remote traffic in a terminal 1: 1. From node 0 to node 1 numactl --membind=1 membw -c 1 -b 200 --write 2. From node 1 to node 0 numactl --membind=0 membw -c 49 -b 200 --write Let's check 'MBR' value for each of the cases in a terminal 2: $ sudo LD_LIBRARY_PATH=lib ./pqos/pqos --iface=os -m "llc:1,49;mbl:1,49;mbr:1,49;mbt:1,49" It will show that MBR is always zero. This is wrong. Remove the wrong calculation that doesn't affect the results for SNC machines and zeroes MBR values for non-SNC ones. |
Roman Storozhenko <roman.storozhenko@intel.com> | no | 2024-07-03 | ||
| 0005-lib-fix-variable-types-in-common.c-pqos_read.patch | [PATCH] lib: fix variable types in common.c:pqos_read() The types used for len and ret variables in pqos_read do not match neither the function prototype, nor read() library call, which may lead to possible overflow; while the ret overflow is arguably hypothetical on Linux, as it likely won't return a value greater than 0x7ffff000, which is less than INT_MAX, a potential overflow of len seems to be possible, as caller might pass count greater than INT_MAX. Fix it by changing the type of len to size_t, to match count, and the type of ret to ssize_t, to match the return type of read(). Discovered by covscan: Error: INTEGER_OVERFLOW (CWE-190): intel-cmt-cat-23.11/lib/common.c:382: tainted_data_return: Called function "read(fd, byte_ptr, len)", and a possible return value may be less than zero. intel-cmt-cat-23.11/lib/common.c:382: cast_overflow: An assign that casts to a different type, which might trigger an overflow. intel-cmt-cat-23.11/lib/common.c:389: overflow: The expression "len" is considered to have possibly overflowed. intel-cmt-cat-23.11/lib/common.c:382: overflow_sink: "len", which might be negative, is passed to "read(fd, byte_ptr, len)". [Note: The source code implementation of the function has been overridden by a builtin model.] # 380| return -1; # 381| # 382|-> while (len != 0 && (ret = read(fd, byte_ptr, len)) != 0) { # 383| if (ret == -1) { # 384| if (errno == EINTR) |
Eugene Syromiatnikov <esyr@redhat.com> | no | 2024-08-16 | ||
| 0006-lib-Fix-calloc-arguments-that-are-in-the-wrong-order.patch | [PATCH] lib: Fix calloc arguments that are in the wrong order Calloc arguments should be (number of items, size of item) but a few of these are the wrong way around, fix them. |
Colin Ian King <colin.i.king@gmail.com> | no | 2025-01-06 |