nmap 7.80 crashes with Assertion `htn.toclock_running == true'

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

apport-collect 1908223

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Thanks for taking the time to report a bug.

I am unable to reproduce the issue here. I've tried it on a Focal lxd container, a Focal VM, and a Focal system (native). I'm always able to execute the following commands:

# sudo nmap -n 192.168.1.1/24
# sudo nmap -4 -vvv -ddd -sn -PR 8.8.8.8

They always work. I even tried to put them inside a while loop, but they don't fail.

Your bug report does make sense to me, but without a reproducer it is hard to justify backporting the patch, especially because we would have to go through the SRU process which is quite strict.

I'm marking this bug as Incomplete for now, and will wait for your reply. When we figure it out how to reproduce it reliably, I can confirm it. Thanks!

I have the same problem.
With root user only.

$ /usr/bin/nmap -sP 192.168.0,10,11,13.*

nmap: Target.cc:503: void Target::stopTimeOutClock(const timeval*): Assertion `htn.toclock_running == true' failed.
Aborted (core dumped)

It only works when setting "-max-parallelism" to a big value.

$ /usr/bin/nmap -sP -max-parallelism 1000 192.168.0,10,11,13.*

As Sergio, I was not able to reproduce the failure locally in my Focal system. From the comments in the upstream bug it seems this is not reliably reproducible, however, to land this fix in Focal and/or Bionic we would need a set of steps that lead us to the bug.

@Stéphane/@Marek could you provide any extra information that could help us to reproduce it?

Dear Ubuntu maintainers, do you have any plans of fixing this bug in Ubuntu 20.04 before Ubuntu 22.04 LTS release?
In upstream nmap it is said to be fixed since version 7.90 .
Do you consider importing version 7.92 into Ubuntu Focal ?
I was able to install nmap 7.91+dfsg1-1 from Ubuntu 20.10 Groovy on my Focal system, which apparently fixed the problem.
But I surely would prefer an official update for Focal.

Hi, I marked the main bug task as Fix Released as this is fixed in >= Hirsute, at least according to the packages versions. I tried to reproduce the bug on Focal but as Sergio and Lucas I wasn't able to. Without a reproducer it's difficult for us to assess the importance of the bug and verify the fix, which are requirements for doing a stable release upgrade [1].

Simply uploading nmap 7.91 to Focal is not an option as that's not how upgrades to stable releases are managed, see again [1]. The TLDR is that we need a minimal, targeted fix. Commit [2] may be it, but I don't see it fitting the SRU requirements without a reproducer. If you're able to provide some step to reproduce the issue we'll certainly consider releasing a fix. Waiting for those I'll mark the Focal task as Incomplete.

[1] https://wiki.ubuntu.com/StableReleaseUpdates
[2] https://github.com/nmap/nmap/commit/33f421fd6e68fcb8ed50071661d9704717c81b2b

Still observing this bug with nmap 7.91+dfsg1+really7.80+dfsg1-2build1 in Ubuntu Jammy (22.04) LTS
Any chances to get it fixed by Apr 2024 ?

Hi Wladimir,

> Any chances to get it fixed by Apr 2024 ?

To reiterate what Paride already answered to your prior inquiry: "I don't see it fitting the SRU requirements without a reproducer. If you're able to provide some step to reproduce the issue we'll certainly consider releasing a fix."

So no, without a reproducer provided by you or others, you should not expect an SRU fix by April. If it's not feasible for you to provide a reproducer, we may be able to provide you with a PPA containing patch 33f421fd, if that would be sufficient for your needs?

On my host I just run
sudo nmap -PS22 -p22 192.168.77.0/24
to get
nmap: Target.cc:503: void Target::stopTimeOutClock(const timeval*): Assertion `htn.toclock_running == true' failed.

I get this message as a rule, while normal completion of the scan is rather exceptional.

I can make you an ssh login and sudo perms on this host. Can't propose any other reproducers right now.

Looks like this is fixed in nmap 7.92 (i.e. in >= Kinetic) by this commit:

  https://github.com/nmap/nmap/commit/33f421fd6e68fcb8ed50071661d9704717c81b2b

I didn't verify that commit actually fixes the issue (I can't reproduce it), but the change looks good for an SRU. This bug report is now actionable.

I'm raising the Importance from Low to Medium as apparently in some cases nmap fails most of the time because of this bug (per Wladimir's comment).

> On my host I just run
> sudo nmap -PS22 -p22 192.168.77.0/24

I've tried this and several other permutations described on this bug and the upstream PRs on my own network, but I also do not reproduce the crash.

From what I understand of the problem, however, it might depend on either the network configuration or on devices present on the network. That may explain why some people see the issue consistently, and others cannot reproduce. There might be some form of race condition involved as well - which could explain why it sometimes works and sometimes doesn't, and why workarounds that change the scanning time resolved it for some people in some cases.

This comment gives some insight into what is going on under the hood, however it's from 2018 and things have changed, so it's only good for background:
  https://github.com/nmap/nmap/issues/1361#issuecomment-431485063

If the issue is caused by a particular machine on your network, you may be able to narrow it down by running the scan on smaller and smaller subsets, e.g.:

$ sudo nmap -PS22 -p22 192.168.77.0-128
$ sudo nmap -PS22 -p22 192.168.77.128-254

If one of those fails but the other doesn't, keep narrowing the range until you can identify it. If it does happen to pinpoint specific machine(s), look at what might be odd about that system.

N.b.: As noted in LP: #1993422 and explained at https://groups.google.com/g/linux.debian.legal/c/XDKSodIvGQQ and https://lwn.net/Articles/842436/, there is uncertainty about the licensing for nmap. This should be taken into account before backporting any patches from versions of nmap covered by this new license.

Following up from my last comment, I think the licensing situation for this patch is ok.

Paride mentioned this issue may have been fixed by a commit included in nmap 7.92.  The license was first announced with version 7.90 on October 2020; specifically, the license change occurred with commit ef8213a on Oct 5th, 2020. However, the commit in question landed on Dec 3, 2019. Thus, it appears to precede the license change.

I was checking the timing of the license vs code change.
As it isn't clarified yet we consider it as a blocker, so the fix must be from before that change.

ef8213a36 is what added the new license in 7.90
80a9f4b2e is the re-stating onto more versions
33f421fd6 is what we'd need to backport here.

$ git log --oneline | grep -e 80a9f4b2e -e ef8213a36 -e 33f421fd6
80a9f4b2e Add the NPSL 0.92 to 0.93 upgrade to the CHANGELOG, noting that Nmap 7.90 and 7.91 may be used under this newer version if desired
ef8213a36 Reintegrate Nmap 7.90 release branch
33f421fd6 Avoid assertion failure when unsolicited ARP response received

So the fix needed here should be still unaffected by this issue and therefore ok to be considered for a backport.

I've packaged the aforementioned patch to this PPA for testing:

    https://launchpad.net/~bryce/+archive/ubuntu/nmap-sru-lp1908223

Users who are able to reproduce this issue (e.g. Wladimir, Stéphane and Marak), please test this PPA in your affected network environment and verify it resolves the problem.

If the issue does not generally occur 100% when running nmap, then make sure to run it repeatedly over a period of days or longer. If possible, when testing run both the PPA version and the stock version, to compare results.

to be fair, I tried to reproduce this fault recently, and I had 473 successful runs until it failed.
simplest loop like

c=0
while sudo nmap -PS22 -p22 192.168.77.0/24
do c=$(($c+1))
      echo $c
done

next time I got 552 successful runs before the fail

now checking with PPA version, will report my results after some time

Now I had >2000 successful runs which easily failed in the past.
As we know, testing can prove only presence of bugs, not their absence.
But statistically, I confirm that nmap behavior has improved with this PPA build.

I have already this bugs with some friends here on Ubuntu 22.04

Thanks for testing Wladimir, based on that I've uploaded the fix for SRU. The next step will be for the SRU team to review and accept this. If they do, they'll ask you to re-verify the package in -proposed is valid both for focal and jammy. Once BOTH are validated the fix will be rolled out officially.

Hello Marek, or anyone else affected,

Accepted nmap into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nmap/7.91+dfsg1+really7.80+dfsg1-2ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Marek, or anyone else affected,

Accepted nmap into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nmap/7.80+dfsg1-2ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

With Jammy-proposed version of nmap package, had 2500+ successful runs of the above script on my home server+network.
Unfortunately I don't have Focal instances anymore, already upgraded everything to Jammy.

Thanks Wladimir! Usually with an SRU we'd wait for focal to also be verified before releasing any of the updates, but this may be a bit of an exception.

With the focal instance, it may be sufficient to have someone run the focal-proposed version of the package and verify that at least it does not cause regression or breakage. Marek, Yoann, or Stephane, would any of you have the ability to install the fix from -proposed this on focal?

The verification of the Stable Release Update for nmap has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package nmap - 7.91+dfsg1+really7.80+dfsg1-2ubuntu0.1

---------------
nmap (7.91+dfsg1+really7.80+dfsg1-2ubuntu0.1) jammy; urgency=medium

  * d/p/avoid-assertion-failure-when-unsolicited-arp-response-received.patch:
    Check if a timeout clock is running before attempting to stop it.
    (LP: #1908223)

 -- Bryce Harrington <email address hidden> Thu, 12 Jan 2023 09:40:55 -0800

The fix for this bug has been awaiting testing feedback in the -proposed repository for focal for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

I can confirm that nmap version 7.80+dfsg1-2ubuntu0.1 from proposed (from ubuntu-ports on a Raspberry Pi) works now where-as before the upgrade I was getting the above error.

This bug was fixed in the package nmap - 7.80+dfsg1-2ubuntu0.1

---------------
nmap (7.80+dfsg1-2ubuntu0.1) focal; urgency=medium

  * d/p/avoid-assertion-failure-when-unsolicited-arp-response-received.patch:
    Check if a timeout clock is running before attempting to stop it.
    (LP: #1908223)

 -- Bryce Harrington <email address hidden> Mon, 30 Jan 2023 01:33:09 -0800