https://bugs.kde.org/show_bug.cgi?id=510416
Mark Wielaard <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Mark Wielaard <[email protected]> --- - NEWS entry now needs to move to new 3.27.0 section - priv_syswrap-linux.h sys_file_[get|set]_attr templates. OK - vki-scnums-shared-linux.h defines common __NR_file_[get|set]attr. OK - vki-linux.h defines new vki_file_attr. OK - syswrap-*-linux.c defines PRE and PRE/POST linux wrappers. OK. - syswrap-linux.c contains multiple lines > 80 chars, meh. - The file descriptor checking (arg1) doesn't make sense in sys_file_getattr. fd == 0 seems a valid file descriptor. And if ARG1 == 0 then of course arg_1 != VKI_AT_FDCWD. It should at least check whether path is absolute [0] == '/'. Why exactly can't the logic from fd_at_check_allowed not be used? - The check should probably be PRE_MEM_WRITE("file_getattr(ufattr)", ARG3, ARG4); - POST file_getattr is commented out? Should probably also be POST_MEM_WRITE(ARG3, ARG4); - PRE file_setattr has PRINT for file_GETattr? - Same odd dfd/filename checking? - last file_setattr PRE check should probably be PRE_MEM_READ("file_setattr(ufattr)", ARG3, ARG4); So two issues (apart from formatting and typos). 1) I don't understand why fd_at_check_allowed cannot be used here. If it really cannot then at least the logic must check for the filepath to be safe to read and start with '/'. The size of the struct given as ARG3 is given as ARG4 (not static so kernel can accept larger structs in the future). -- You are receiving this mail because: You are watching all bug changes.
