[systemd-devel] systemd failing to close unwanted file descriptors & FDS spawning and crashing

[Christopher Obbard]

Hi Lennart,

On 04/03/2022 09:44, Lennart Poettering wrote:
> On Fr, 04.03.22 09:26, Christopher Obbard (chris.obbard at collabora.com) wrote:
> 
>> Right, so it looks like the call to close_range fails. This is a 5.4 kernel
>> which doesn;t have close_range - so this is understandable.
>>
>> For a quick fix, I set have_close_range to false - see the patch attached.
>> It seemed to work well.
>>
>> Since my 5.4 kernel is a heavily modified downstream one - next I will check
>> if that syscall was implemented by someone else, and also I will check if
>> vanilla systemd works on vanilla 5.4 (there is no reason why it shouldn't,
>> right?).
> 
> Hmm, this is strange. Our code already has fallback paths in place to
> handle cases where the syscall is not implemented, i.e. where we see
> ENOSYS when we call it. Our code should handle this perfectly already.
> 
> Is it possible that your patched kernel added non-standard syscalls
> under the syscall numbers the official kernel later assigned to
> close_range()? If so, this would explain that we see EINVAL, as of
> course we call the syscall assuming it was close_range(), but if it is
> actually something else mit very likely might not be able to make
> sense of our parameters and thus return EINVAL.
> 
> In this case I am not very sympathetic to your case: squatting syscall
> numbers is just a terrible idea...

Even worse: it turns out they backported the process_madvise syscall to 
5.4 and changed the syscall number to be the same as close_range.

There are terrible ideas, then there is just being plain evil ;-).

Thanks for all the help.
Chris