From 7dd3ed26ca09df0e582be8cc2780bba588bdd11e Mon Sep 17 00:00:00 2001 From: P Dheeraj Srujan Kumar Date: Fri, 2 Dec 2022 23:23:31 +0530 Subject: Update to internal 1-0.92 Signed-off-by: P Dheeraj Srujan Kumar --- .../linux/linux-aspeed/CVE-2022-32296.patch | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-32296.patch (limited to 'meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-32296.patch') diff --git a/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-32296.patch b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-32296.patch new file mode 100644 index 000000000..5772f7e13 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-kernel/linux/linux-aspeed/CVE-2022-32296.patch @@ -0,0 +1,61 @@ +From dff5a6126ede802f8df7485b122bf265ad7c69aa Mon Sep 17 00:00:00 2001 +From: Manish Baing +Date: Tue, 21 Jun 2022 05:44:53 +0000 +Subject: [PATCH] tcp: increase source port perturb table to 2^16 + +Moshe Kol, Amit Klein, and Yossi Gilad reported being able to accurately +identify a client by forcing it to emit only 40 times more connections +than there are entries in the table_perturb[] table. The previous two +improvements consisting in resalting the secret every 10s and adding +randomness to each port selection only slightly improved the situation, +and the current value of 2^8 was too small as it's not very difficult +to make a client emit 10k connections in less than 10 seconds. + +Thus we're increasing the perturb table from 2^8 to 2^16 so that the +same precision now requires 2.6M connections, which is more difficult in +this time frame and harder to hide as a background activity. The impact +is that the table now uses 256 kB instead of 1 kB, which could mostly +affect devices making frequent outgoing connections. However such +components usually target a small set of destinations (load balancers, +database clients, perf assessment tools), and in practice only a few +entries will be visited, like before. + +A live test at 1 million connections per second showed no performance +difference from the previous value. + +Reported-by: Moshe Kol +Reported-by: Yossi Gilad +Reported-by: Amit Klein +Reviewed-by: Eric Dumazet +Signed-off-by: Willy Tarreau +Signed-off-by: Jakub Kicinski + +Source: https://github.com/openbmc/linux/commit/4c2c8f03a5ab7cb04ec64724d7d176d00bcc91e5 +--- + net/ipv4/inet_hashtables.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c +index bfb522e51346..86efce0cf4eb 100644 +--- a/net/ipv4/inet_hashtables.c ++++ b/net/ipv4/inet_hashtables.c +@@ -715,11 +715,12 @@ EXPORT_SYMBOL_GPL(inet_unhash); + * Note that we use 32bit integers (vs RFC 'short integers') + * because 2^16 is not a multiple of num_ephemeral and this + * property might be used by clever attacker. +- * RFC claims using TABLE_LENGTH=10 buckets gives an improvement, +- * we use 256 instead to really give more isolation and +- * privacy, this only consumes 1 KB of kernel memory. ++ * RFC claims using TABLE_LENGTH=10 buckets gives an improvement, though ++ * attacks were since demonstrated, thus we use 65536 instead to really ++ * give more isolation and privacy, at the expense of 256kB of kernel ++ * memory. + */ +-#define INET_TABLE_PERTURB_SHIFT 8 ++#define INET_TABLE_PERTURB_SHIFT 16 + static u32 table_perturb[1 << INET_TABLE_PERTURB_SHIFT]; + + int __inet_hash_connect(struct inet_timewait_death_row *death_row, +-- +2.17.1 + -- cgit v1.2.3