CVE-2023-53742

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcsan: Avoid READ_ONCE() in read_instrumented_memory()<br /> <br /> Haibo Li reported:<br /> <br /> | Unable to handle kernel paging request at virtual address<br /> | ffffff802a0d8d7171<br /> | Mem abort info:o:<br /> | ESR = 0x9600002121<br /> | EC = 0x25: DABT (current EL), IL = 32 bitsts<br /> | SET = 0, FnV = 0 0<br /> | EA = 0, S1PTW = 0 0<br /> | FSC = 0x21: alignment fault<br /> | Data abort info:o:<br /> | ISV = 0, ISS = 0x0000002121<br /> | CM = 0, WnR = 0 0<br /> | swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000002835200000<br /> | [ffffff802a0d8d71] pgd=180000005fbf9003, p4d=180000005fbf9003,<br /> | pud=180000005fbf9003, pmd=180000005fbe8003, pte=006800002a0d8707<br /> | Internal error: Oops: 96000021 [#1] PREEMPT SMP<br /> | Modules linked in:<br /> | CPU: 2 PID: 45 Comm: kworker/u8:2 Not tainted<br /> | 5.15.78-android13-8-g63561175bbda-dirty #1<br /> | ...<br /> | pc : kcsan_setup_watchpoint+0x26c/0x6bc<br /> | lr : kcsan_setup_watchpoint+0x88/0x6bc<br /> | sp : ffffffc00ab4b7f0<br /> | x29: ffffffc00ab4b800 x28: ffffff80294fe588 x27: 0000000000000001<br /> | x26: 0000000000000019 x25: 0000000000000001 x24: ffffff80294fdb80<br /> | x23: 0000000000000000 x22: ffffffc00a70fb68 x21: ffffff802a0d8d71<br /> | x20: 0000000000000002 x19: 0000000000000000 x18: ffffffc00a9bd060<br /> | x17: 0000000000000001 x16: 0000000000000000 x15: ffffffc00a59f000<br /> | x14: 0000000000000001 x13: 0000000000000000 x12: ffffffc00a70faa0<br /> | x11: 00000000aaaaaaab x10: 0000000000000054 x9 : ffffffc00839adf8<br /> | x8 : ffffffc009b4cf00 x7 : 0000000000000000 x6 : 0000000000000007<br /> | x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffffc00a70fb70<br /> | x2 : 0005ff802a0d8d71 x1 : 0000000000000000 x0 : 0000000000000000<br /> | Call trace:<br /> | kcsan_setup_watchpoint+0x26c/0x6bc<br /> | __tsan_read2+0x1f0/0x234<br /> | inflate_fast+0x498/0x750<br /> | zlib_inflate+0x1304/0x2384<br /> | __gunzip+0x3a0/0x45c<br /> | gunzip+0x20/0x30<br /> | unpack_to_rootfs+0x2a8/0x3fc<br /> | do_populate_rootfs+0xe8/0x11c<br /> | async_run_entry_fn+0x58/0x1bc<br /> | process_one_work+0x3ec/0x738<br /> | worker_thread+0x4c4/0x838<br /> | kthread+0x20c/0x258<br /> | ret_from_fork+0x10/0x20<br /> | Code: b8bfc2a8 2a0803f7 14000007 d503249f (78bfc2a8) )<br /> | ---[ end trace 613a943cb0a572b6 ]-----<br /> <br /> The reason for this is that on certain arm64 configuration since<br /> e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when<br /> CONFIG_LTO=y"), READ_ONCE() may be promoted to a full atomic acquire<br /> instruction which cannot be used on unaligned addresses.<br /> <br /> Fix it by avoiding READ_ONCE() in read_instrumented_memory(), and simply<br /> forcing the compiler to do the required access by casting to the<br /> appropriate volatile type. In terms of generated code this currently<br /> only affects architectures that do not use the default READ_ONCE()<br /> implementation.<br /> <br /> The only downside is that we are not guaranteed atomicity of the access<br /> itself, although on most architectures a plain load up to machine word<br /> size should still be atomic (a fact the default READ_ONCE() still relies<br /> on itself).