-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Account for kernel.pid_max > 65535 #13
Conversation
Thanks! Looking at https://github.com/matusmarhefka/dfuzzer/pull/8 I think |
Your approach is clearly more thorough! I just solve the problem at hand in #8 . |
@mrc0mmand @evverx Due to my job duties I am not always able to respond in timely manner to the PRs in this project (even though I try to review/merge PRs when I can). I am glad that people are still interested and use this project and I am okay with giving you merge rights to this repository if you plan to continue working on more improvements/fixes. Please let me know if you are interested. |
@matusmarhefka I think as long as
To make it easier to integrate |
@matusmarhefka btw we could create a generic |
@thrix I'm not particularly familiar with |
Just to clarify, I'm not saying that |
@evverx I see, I was more targetting other components which have DBus interfaces, I understand |
@thrix I agree in most cases it should be possible to automate that with |
It would be definitely great to move the development back to this repository, since the systemd fork was meant to be just temporary. Once I get a bit of a spare time, I could cherry-pick the newly introduced patches and open the respective PRs. |
@thrix Sounds good, so your idea is to provide a generic tmt test in this repo which could be parametrized with bus name? Btw I was also thinking about introducing Packit and Testing Farm support in this repository. |
@mrc0mmand That would be great. I can give you guys commit rights so you can review and merge new PRs. Can I add you @mrc0mmand and also @evverx ? |
@mrc0mmand @evverx I've added you as collaborators, so you should now have commit rights :) |
@matusmarhefka thanks!
FWIW to make sure Also LGTM was integrated there: https://lgtm.com/projects/g/systemd/systemd-dfuzzer/alerts/?mode=tree. I added the dffuzer repository to LGTM as well: https://lgtm.com/projects/g/matusmarhefka/dfuzzer?mode=tree but since I'm not the owner I can't install it to the repository to make it analyze PRs. Could you install LGTM to the dfuzzer repository: https://lgtm.com/projects/g/matusmarhefka/dfuzzer/ci? |
Done. |
Thanks! It seems to be working. I've just opened https://github.com/matusmarhefka/dfuzzer/pull/14 (where the C code is analyzed is well). Without that patch only the python code is covered. |
FWIW @mrc0mmand fixed most issues LGTM found so I'd just ignore the alerts until patches like systemd/systemd-dfuzzer#6 are backported. |
Thanks, again, for all the work and sorry for the delay, a lot of stuff has piled up. I've started going through the patches and opened #15 in the first batch. To continue further, I need this PR to get merged to avoid conflicts, so once #15 is approved & merged, I'll rebase this one to trigger CIs to move it forward. |
Today's `kernel.pid_max=` is usually set to 2^22 (4194304) instead of the original 2^16 (65535), causing buffer overflow when trying to write `/proc/<PID>/cmdline` into the stack-allocated buffer. Let's fix this by using the maximum "string length" of int (calculated using a macro borrowed from systemd, which might be useful in the future). Fixes: dbus-fuzzer#11
c29e0be
to
a1b02d3
Compare
@matusmarhefka I opened https://github.com/matusmarhefka/dfuzzer/issues/20 so that this thread won't get lost.
@matusmarhefka now that I started fiddling with LDFLAGS I'm a bit concerned that I can accidentally break the package so I think it would be great to integrate Packit here. Could you install https://github.com/marketplace/packit-as-a-service? Once it's installed I'll add |
Yes, and that test could be provided by this repo, a user could then run it via Testing Farm very easily. And it could also serve as a sanity test :) I will open an issue and provide a PR. |
Today's
kernel.pid_max=
is usually set to 2^22 (4194304) instead ofthe original 2^16 (65535), causing buffer overflow when trying to write
/proc/<PID>/cmdline
into the stack-allocated buffer. Let's fix this byusing the maximum "string length" of int (calculated using a macro
borrowed from systemd, which might be useful in the future).
Fixes: #11