Messages in this thread | | | From | Christophe Leroy <> | Subject | Re: [PATCH bpf-next 1/2] bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() | Date | Mon, 19 Feb 2024 06:39:33 +0000 |
| |
Le 19/02/2024 à 02:40, Hengqi Chen a écrit : > [Vous ne recevez pas souvent de courriers de hengqi.chen@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] > > Hello Christophe, > > On Sun, Feb 18, 2024 at 6:55 PM Christophe Leroy > <christophe.leroy@csgroup.eu> wrote: >> >> set_memory_ro() can fail, leaving memory unprotected. >> >> Check its return and take it into account as an error. >> > > I don't see a cover letter for this series, could you describe how > set_memory_ro() could fail. > (Most callsites of set_memory_ro() didn't check the return values)
Yeah, there is no cover letter because as explained in patch 2 the two patches are autonomous. The only reason why I sent it as a series is because the patches both modify include/linux/filter.h in two places that are too close to each other.
I should have added a link to https://github.com/KSPP/linux/issues/7 See that link for detailed explanation.
If we take powerpc as an exemple, set_memory_ro() is a frontend to change_memory_attr(). When you look at change_memory_attr() you see it can return -EINVAL in two cases. Then it calls apply_to_existing_page_range(). When you go down the road you see you can get -EINVAL or -ENOMEM from that function or its callees.
Christophe
| |