From: Chen Jiahao <chenjiahao16(a)huawei.com>
hulk inclusion
category: bugfix
bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960
--------------------------------
In cpufeature.c, when num is set to ARM64_SPECTRE_BHB, it should
not be passed to cpu_hwcap_keys, otherwise the out-of-range error
would happen as below:
UBSAN: Undefined behaviour in arch/arm64/kernel/cpufeature.c:1742:3
index 40 is out of range for type 'static_key_false [39]'
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.90+ #1
Call trace:
dump_backtrace+0x0/0x390
show_stack+0x24/0x30
dump_stack+0x130/0x188
ubsan_epilogue+0x14/0xa4
__ubsan_handle_out_of_bounds+0x144/0x184
__enable_cpu_capabilities+0x158/0x1d4
setup_cpu_features+0x34/0xc8
smp_cpus_done+0x44/0x13c
smp_init+0x188/0x1a4
kernel_init_freeable+0x454/0x974
kernel_init+0x18/0x150
ret_from_fork+0x10/0x18
Because KABI cpu_hwcap_keys is consistent and defined with length
ARM64_NCAPS, which is smaller than ARM64_SPECTRE_BHB.
Fixes: 2df7cf898c5b ("arm64: fix extra cpucaps setup problem")
Signed-off-by: Chen Jiahao <chenjiahao16(a)huawei.com>
Reviewed-by: Liao Chang <liaochang1(a)huawei.com>
Reviewed-by: Zhang Jianhua <chris.zjh(a)huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com>
---
arch/arm64/kernel/cpufeature.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 996d3476f3c8..d7d8a4ab94b4 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1732,8 +1732,10 @@ __enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
for (; caps->matches; caps++) {
unsigned int num = caps->capability;
- if (num == ARM64_SPECTRE_BHB)
+ if (num == ARM64_SPECTRE_BHB) {
set_cap_spectre_bhb = true;
+ continue;
+ }
if (!(caps->type & scope_mask) || !cpus_have_cap(num))
continue;
--
2.25.1
Hi all:
These patches are used to resolve the xfs problem when perform
xfstests. For details about how to fix the problem, we can see the
link below:
https://lore.kernel.org/linux-xfs/154697976479.2839.3584921201780682011.stg…https://lore.kernel.org/linux-xfs/157232182246.593721.4902116478429075171.s…
Thanks
---
Darrick J. Wong (8):
xfs: abort xattr scrub if fatal signals are pending
xfs: scrub should flag dir/attr offsets that aren't mappable with
xfs_dablk_t
xfs: check directory name validity
xfs: check attribute name validity
xfs: check attribute leaf block structure
xfs: namecheck attribute names before listing them
xfs: namecheck directory entry names before listing them
xfs: replace -EIO with -EFSCORRUPTED for corrupt metadata
fs/xfs/libxfs/xfs_attr.c | 17 +++++++++
fs/xfs/libxfs/xfs_attr.h | 2 +-
fs/xfs/libxfs/xfs_attr_leaf.c | 68 +++++++++++++++++++++++++++++++++--
fs/xfs/libxfs/xfs_attr_leaf.h | 4 +--
fs/xfs/libxfs/xfs_bmap.c | 6 ++--
fs/xfs/libxfs/xfs_dir2.c | 17 +++++++++
fs/xfs/libxfs/xfs_dir2.h | 1 +
fs/xfs/libxfs/xfs_types.c | 11 ++++++
fs/xfs/libxfs/xfs_types.h | 1 +
fs/xfs/scrub/attr.c | 11 ++++++
fs/xfs/scrub/bmap.c | 27 ++++++++++++++
fs/xfs/scrub/dir.c | 6 ++++
fs/xfs/xfs_attr_inactive.c | 6 ++--
fs/xfs/xfs_attr_list.c | 60 ++++++++++++++++++++-----------
fs/xfs/xfs_dir2_readdir.c | 27 +++++++++++---
fs/xfs/xfs_dquot.c | 2 +-
16 files changed, 228 insertions(+), 38 deletions(-)
--
2.18.4
From: Eric Dumazet <edumazet(a)google.com>
stable inclusion
from stable-v4.19.246
commit ddec440133913a6b8880e53b896d521a4b7ff24f
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5C3A9
CVE: CVE-2022-32296
--------------------------------
commit 190cc82489f46f9d88e73c81a47e14f80a791e1a upstream.
RFC 6056 (Recommendations for Transport-Protocol Port Randomization)
provides good summary of why source selection needs extra care.
David Dworken reminded us that linux implements Algorithm 3
as described in RFC 6056 3.3.3
Quoting David :
In the context of the web, this creates an interesting info leak where
websites can count how many TCP connections a user's computer is
establishing over time. For example, this allows a website to count
exactly how many subresources a third party website loaded.
This also allows:
- Distinguishing between different users behind a VPN based on
distinct source port ranges.
- Tracking users over time across multiple networks.
- Covert communication channels between different browsers/browser
profiles running on the same computer
- Tracking what applications are running on a computer based on
the pattern of how fast source ports are getting incremented.
Section 3.3.4 describes an enhancement, that reduces
attackers ability to use the basic information currently
stored into the shared 'u32 hint'.
This change also decreases collision rate when
multiple applications need to connect() to
different destinations.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: David Dworken <ddworken(a)google.com>
Cc: Willem de Bruijn <willemb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
[SG: Adjusted context]
Signed-off-by: Stefan Ghinea <stefan.ghinea(a)windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Conflicts:
net/ipv4/inet_hashtables.c
Signed-off-by: Baisong Zhong <zhongbaisong(a)huawei.com>
Reviewed-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Reviewed-by: Xiu Jianfeng <xiujianfeng(a)huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com>
---
net/ipv4/inet_hashtables.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index bd0108aaa45b..72b8b6f44add 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -666,6 +666,17 @@ void inet_unhash(struct sock *sk)
}
EXPORT_SYMBOL_GPL(inet_unhash);
+/* RFC 6056 3.3.4. Algorithm 4: Double-Hash Port Selection Algorithm
+ * 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.
+ */
+#define INET_TABLE_PERTURB_SHIFT 8
+static u32 table_perturb[1 << INET_TABLE_PERTURB_SHIFT];
+
int __inet_hash_connect(struct inet_timewait_death_row *death_row,
struct sock *sk, u64 port_offset,
int (*check_established)(struct inet_timewait_death_row *,
@@ -679,8 +690,8 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row,
struct inet_bind_bucket *tb;
u32 remaining, offset;
int ret, i, low, high;
- static u32 hint;
int l3mdev;
+ u32 index;
if (port) {
head = &hinfo->bhash[inet_bhashfn(net, port,
@@ -707,7 +718,10 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row,
if (likely(remaining > 1))
remaining &= ~1U;
- offset = hint + port_offset;
+ net_get_random_once(table_perturb, sizeof(table_perturb));
+ index = hash_32(port_offset, INET_TABLE_PERTURB_SHIFT);
+
+ offset = READ_ONCE(table_perturb[index]) + port_offset;
offset %= remaining;
/* In first pass we try ports of @low parity.
* inet_csk_get_port() does the opposite choice.
@@ -762,7 +776,7 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row,
return -EADDRNOTAVAIL;
ok:
- hint += i + 2;
+ WRITE_ONCE(table_perturb[index], READ_ONCE(table_perturb[index]) + i + 2);
/* Head lock still held and bh's disabled */
inet_bind_hash(sk, tb, port);
--
2.25.1