The ordering fallbacks for atomic*_read_acquire() and
atomic*_set_release() erroneously fall back to the implictly relaxed
atomic*_read() and atomic*_set() variants respectively, without any
additional barriers. This loses the ACQUIRE and RELEASE ordering
semantics, which can result in a wide variety of problems, even on
strongly-ordered architectures where the implementation of
atomic*_read() and/or atomic*_set() allows the compiler to reorder those
relative to other accesses.
In practice this has been observed to break bit spinlocks on arm64,
resulting in dentry cache corruption.
The fallback logic was intended to allow ACQUIRE/RELEASE/RELAXED ops to
be defined in terms of FULL ops, but where an op had RELAXED ordering by
default, this unintentionally permitted the ACQUIRE/RELEASE ops to be
defined in terms of the implicitly RELAXED default.
This patch corrects the logic to avoid falling back to implicitly
RELAXED ops, resulting in the same behaviour as prior to commit
9257959a6e5b4fca.
I've verified the resulting assembly on arm64 by generating outlined
wrappers of the atomics. Prior to this patch the compiler generates
sequences using relaxed load (LDR) and store (STR) instructions, e.g.
| <outlined_atomic64_read_acquire>:
| ldr x0, [x0]
| ret
|
| <outlined_atomic64_set_release>:
| str x1, [x0]
| ret
With this patch applied the compiler generates sequences using the
intended load-acquire (LDAR) and store-release (STLR) instructions, e.g.
| <outlined_atomic64_read_acquire>:
| ldar x0, [x0]
| ret
|
| <outlined_atomic64_set_release>:
| stlr x1, [x0]
| ret
To make sure that there were no other victims of the ifdeffery rewrite,
I generated outlined copies of all of the {atomic,atomic64,atomic_long}
atomic operations before and after commit 9257959a6e5b4fca. A diff of
the generated assembly on arm64 shows that only the read_acquire() and
set_release() operations were changed, and only lost their intended
ordering:
I've build tested this with a variety of configs for alpha, arm, arm64,
csky, i386, m68k, microblaze, mips, nios2, openrisc, powerpc, riscv,
s390, sh, sparc, x86_64, and xtensa, for which I've seen no issues. I
was unable to build test for ia64 and parisc due to existing build
breakage in v6.6-rc2.
Fixes: 9257959a6e5b4fca ("locking/atomic: scripts: restructure fallback ifdeffery")
Reported-by: Ming Lei <email address hidden>
Reported-by: Darrick J. Wong <email address hidden>
Signed-off-by: Mark Rutland <email address hidden>
Signed-off-by: Peter Zijlstra (Intel) <email address hidden>
Tested-by: Baokun Li <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
(cherry picked from commit 2eebf58ce030526a08b973e63137b2f104646f64 linux-6.5.6)
Signed-off-by: Roxana Nicolescu <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Manuel Diewald <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>
UBUNTU: [Config] Move some annotations config options
CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING has moved from
'Annotations without notes' because it has a tracker in the note and
CONFIG_WWAN has moved further up due to lexical sort.
drm/vmwgfx: Keep a gem reference to user bos in surfaces
Surfaces can be backed (i.e. stored in) memory objects (mob's) which
are created and managed by the userspace as GEM buffers. Surfaces
grab only a ttm reference which means that the gem object can
be deleted underneath us, especially in cases where prime buffer
export is used.
Forget to reset ctx->password to NULL will lead to bug like double free
Cc: <email address hidden>
Cc: Willy Tarreau <w@1wt.eu>
Reviewed-by: Namjae Jeon <email address hidden>
Signed-off-by: Quang Le <email address hidden>
Signed-off-by: Steve French <email address hidden>
(cherry picked from commit e6e43b8aa7cd3c3af686caf0c2e11819a886d705)
CVE-2023-5345
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
56bb6c7...
by
Wander Lairson Costa <email address hidden>
netfilter: nfnetlink_osf: avoid OOB read
The opt_num field is controlled by user mode and is not currently
validated inside the kernel. An attacker can take advantage of this to
trigger an OOB read and potentially leak information.
BUG: KASAN: slab-out-of-bounds in nf_osf_match_one+0xbed/0xd10 net/netfilter/nfnetlink_osf.c:88
Read of size 2 at addr ffff88804bc64272 by task poc/6431
Also add validation to genre, subtype and version fields.
Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match")
Reported-by: Lucas Leong <email address hidden>
Signed-off-by: Wander Lairson Costa <email address hidden>
Signed-off-by: Florian Westphal <email address hidden>
CVE-2023-39189
(cherry picked from commit f4f8a7803119005e87b716874bec07c751efafec)
Signed-off-by: Magali Lemes <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
437bbb6...
by
Pablo Neira Ayuso <email address hidden>
netfilter: nft_set_rbtree: skip sync GC for new elements in this transaction
New elements in this transaction might expired before such transaction
ends. Skip sync GC for such elements otherwise commit path might walk
over an already released object. Once transaction is finished, async GC
will collect such expired element.
Fixes: f6c383b8c31a ("netfilter: nf_tables: adapt set backend to use GC transaction API")
Signed-off-by: Pablo Neira Ayuso <email address hidden>
Signed-off-by: Florian Westphal <email address hidden>
CVE-2023-4244
(cherry picked from commit 2ee52ae94baabf7ee09cf2a8d854b990dac5d0e4)
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
lxc and lxd currently need to determine if the apparmor restriction
on unprivileged user namespaces are being enforced, so that apparmor
restrictions won't break lxc/d, and they won't clutter the logs
by doing something like
unshare true
to test if the restrictions are being enforced.
Ideally access to this information would be restricted so that any
unknown access would be logged, but lxc/d currently aren't ready for
this so in order to _not_ force lxc/d to probe whether enforcement is
enabled, open up read access to the sysctls for unprivileged user
namespace mediation.
Signed-off-by: John Johansen <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Roxana Nicolescu <email address hidden>
