On 2025-02-25 at 20:12:40 +0100, Maciej Wieczor-Retman wrote: >On 2025-02-25 at 18:20:08 +0100, Maciej Wieczor-Retman wrote: >>On 2025-02-22 at 16:06:02 +0100, Andrey Konovalov wrote: >>>On Fri, Feb 21, 2025 at 2:12 PM Maciej Wieczor-Retman >>><maciej.wieczor-retman@xxxxxxxxx> wrote: >>>> > Thus, the possible values a shadow address can >>>> >take are the result of the memory-to-shadow mapping applied to >>>> >[0xff00000000000000, 0xffffffffffffffff], not to the whole address >>>> >space. So we can make this check more precise. >>>> >>>> In case my question above didn't lead to this: what happens to the rest of the >>>> values if they get plugged into kasan_mem_to_shadow()? >>> >>>We will get some invalid addresses. But this should never happen in >>>the first place. >> >>Thanks for letting me know about the tag resets, that should make changing the >>check in kasan_non_canonical_hook() easier. > >Ah, but the [0xff00000000000000, 0xffffffffffffffff] won't be true for x86 >right? Here the tag reset function only resets bits 60:57. So I presume >[0x3e00000000000000, 0xffffffffffffffff] would be the range? Sorry, brain freeze, I meant [0x1e00000000000000, 0xffffffffffffffff] -- Kind regards Maciej Wieczór-Retman
