[google/syzkaller] d1185f: executor: linux: fix syz_open_dev virtual file nam...
3 views
Skip to first unread message
Florent Revest
Jun 4, 2025, 4:08:42 AM6/4/25
to syzk...@googlegroups.com
Branch: refs/heads/gh-readonly-queue/master/pr-6068-a30356b7cec03128d4d1600947b636ea5206732f
Home: https://github.com/google/syzkaller
Commit: d1185f71a0ae0131a1dc76c72c8a176ee8045835
https://github.com/google/syzkaller/commit/d1185f71a0ae0131a1dc76c72c8a176ee8045835
Author: Florent Revest <rev...@chromium.org>
Date: 2025-06-04 (Wed, 04 Jun 2025)
Changed paths:
M executor/common_linux.h
Log Message:
-----------
executor: linux: fix syz_open_dev virtual file names range
We noticed that syzkaller left some files with fairly unusual file names
under /dev. Eg:
---------- 1 root root 0 May 30 14:42 vcs-
---------- 1 root root 0 May 30 14:48 vcs.
---------- 1 root root 136317631 May 30 14:42 vcs'
---------- 1 root root 0 May 30 14:48 vcs(
---------- 1 root root 0 May 30 14:43 vcs)
---------- 1 root root 0 May 30 14:43 vcs*
---------- 1 root root 136317633 May 30 14:46 vcs+
Funnily enough the characters after "vcs" are always within the '0'-10
to '0' ASCII range. We noticed that the syz_open_dev logic uses a modulo
10 on a signed number (the volatile long a1 argument) and in C the
modulo of a negative number stays negative, so the result of this
operation is in the '0'-10 to '0'+10 range. This is in turn casted to a
char which is also signed and doesn't fix the glitch.
By casting a1 to an unsigned long first, this keeps the result of the
modulo operation signed and therefore the virtual file name suffix a
number.
Commit: e565f08d1cb546967f255601a17a0c958d06ce6d
https://github.com/google/syzkaller/commit/e565f08d1cb546967f255601a17a0c958d06ce6d
Author: Florent Revest <rev...@chromium.org>
Date: 2025-06-04 (Wed, 04 Jun 2025)
Changed paths:
M executor/common_linux.h
Log Message:
-----------
executor: linux: make syz_open_dev comment more correct
The logic in that branch of the code relies on replacing # characters
with numbers. There's a comment in the code which shows a clarifying
example but it misses the # which I found mildly confusing.
Compare: https://github.com/google/syzkaller/compare/d1185f71a0ae%5E...e565f08d1cb5
To unsubscribe from these emails, change your notification settings at https://github.com/google/syzkaller/settings/notifications
Home: https://github.com/google/syzkaller
Commit: d1185f71a0ae0131a1dc76c72c8a176ee8045835
https://github.com/google/syzkaller/commit/d1185f71a0ae0131a1dc76c72c8a176ee8045835
Author: Florent Revest <rev...@chromium.org>
Date: 2025-06-04 (Wed, 04 Jun 2025)
Changed paths:
M executor/common_linux.h
Log Message:
-----------
executor: linux: fix syz_open_dev virtual file names range
We noticed that syzkaller left some files with fairly unusual file names
under /dev. Eg:
---------- 1 root root 0 May 30 14:42 vcs-
---------- 1 root root 0 May 30 14:48 vcs.
---------- 1 root root 136317631 May 30 14:42 vcs'
---------- 1 root root 0 May 30 14:48 vcs(
---------- 1 root root 0 May 30 14:43 vcs)
---------- 1 root root 0 May 30 14:43 vcs*
---------- 1 root root 136317633 May 30 14:46 vcs+
Funnily enough the characters after "vcs" are always within the '0'-10
to '0' ASCII range. We noticed that the syz_open_dev logic uses a modulo
10 on a signed number (the volatile long a1 argument) and in C the
modulo of a negative number stays negative, so the result of this
operation is in the '0'-10 to '0'+10 range. This is in turn casted to a
char which is also signed and doesn't fix the glitch.
By casting a1 to an unsigned long first, this keeps the result of the
modulo operation signed and therefore the virtual file name suffix a
number.
Commit: e565f08d1cb546967f255601a17a0c958d06ce6d
https://github.com/google/syzkaller/commit/e565f08d1cb546967f255601a17a0c958d06ce6d
Author: Florent Revest <rev...@chromium.org>
Date: 2025-06-04 (Wed, 04 Jun 2025)
Changed paths:
M executor/common_linux.h
Log Message:
-----------
executor: linux: make syz_open_dev comment more correct
The logic in that branch of the code relies on replacing # characters
with numbers. There's a comment in the code which shows a clarifying
example but it misses the # which I found mildly confusing.
Compare: https://github.com/google/syzkaller/compare/d1185f71a0ae%5E...e565f08d1cb5
To unsubscribe from these emails, change your notification settings at https://github.com/google/syzkaller/settings/notifications
Florent Revest
Jun 4, 2025, 4:21:25 AM6/4/25
to syzk...@googlegroups.com
Branch: refs/heads/master
Compare: https://github.com/google/syzkaller/compare/a30356b7cec0...e565f08d1cb5
Reply all
Reply to author
Forward
0 new messages