/usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

Bug #1580385 reported by errors.ubuntu.com bug bridge
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
lua-lpeg (Debian)
Fix Released
Unknown
lua-lpeg (Ubuntu)
Fix Released
Medium
Victor Tapia
Xenial
Fix Released
Medium
Victor Tapia
Bionic
Fix Released
Medium
Victor Tapia
Disco
Fix Released
Medium
Victor Tapia
Eoan
Fix Released
Medium
Victor Tapia

Bug Description

[Impact]

Under certain conditions, lpeg will crash while walking the pattern tree looking for TCapture nodes.

[Test Case]

The reproducer, taken from an upstream discussion (link in "Other info"), is:

$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"

p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")

The program crashes due to a hascaptures() infinite recursion:

$ ./repro.lua
Segmentation fault (core dumped)

(gdb) bt -25
#523984 0x00007ffff7a3743c in hascaptures () from /usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523985 0x00007ffff7a3743c in hascaptures () from /usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523986 0x00007ffff7a3743c in hascaptures () from /usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523987 0x00007ffff7a3743c in hascaptures () from /usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523988 0x00007ffff7a3743c in hascaptures () from /usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523989 0x00007ffff7a3743c in hascaptures () from /usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523990 0x00007ffff7a3815c in ?? () from /usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523991 0x00007ffff7a388e3 in compile () from /usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523992 0x00007ffff7a36fab in ?? () from /usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523993 0x000055555555fd1e in ?? ()
#523994 0x000055555556a5fc in ?? ()
#523995 0x00005555555600c8 in ?? ()
#523996 0x000055555555f63f in ?? ()
#523997 0x000055555556030f in ?? ()
#523998 0x000055555555dc91 in lua_pcallk ()
#523999 0x000055555555b896 in ?? ()
#524000 0x000055555555c54b in ?? ()
#524001 0x000055555555fd1e in ?? ()
#524002 0x0000555555560092 in ?? ()
#524003 0x000055555555f63f in ?? ()
#524004 0x000055555556030f in ?? ()
#524005 0x000055555555dc91 in lua_pcallk ()
#524006 0x000055555555b64b in ?? ()
#524007 0x00007ffff7c94bbb in __libc_start_main (main=0x55555555b5f0, argc=2, argv=0x7fffffffe6d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe6c8)
    at ../csu/libc-start.c:308
#524008 0x000055555555b70a in ?? ()

The expected behavior is to have the program finish normally

[Regression potential]

Low, this is a backport from upstream and only limits the infinite recursion in a scenario where it shouldn't happen to begin with (TCapture node search).
[Other info]

This was fixed upstream in 1.0.1 by stopping the recursion in TCall nodes and controlling that TRule nodes do not follow siblings (sib2)

The upstream discussion can be found here: http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-td7674831.html

My analysis can be found here: http://pastebin.ubuntu.com/p/n4824ftZt9/plain/

[Original description]

The Ubuntu Error Tracker has been receiving reports about a problem regarding nmap. This problem was most recently seen with version 7.01-2ubuntu2, the problem page at https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f contains more details.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nmap (Ubuntu):
status: New → Confirmed
Changed in nmap (Ubuntu):
importance: Undecided → High
Eric Desrochers (slashd)
tags: added: sts
Revision history for this message
Eric Desrochers (slashd) wrote :

It really seems to be a problem inside lua-lpeg (0.12.2-1) found in Xenial, and seemed to have been fix (reading the upstream bug) in 1.0.0 found in Bionic and late.

Which also explain why when tried with Bionic the issue was not reproducible.

# rmadison
 lua-lpeg | 0.12.2-1 | xenial
 lua-lpeg | 1.0.0-2 | bionic/universe
 lua-lpeg | 1.0.0-2 | disco/universe
 lua-lpeg | 1.0.0-2 | eoan/universe

Reference:
http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-td7674831.html
https://github.com/nmap/nmap/pull/478

Revision history for this message
Eric Desrochers (slashd) wrote :

It has been brought to my attention that 'nmap -sV' randomly segfault in Xenial.
I was also able to reproduce the situation.

It seems to be caused by a stack exhaustion due to a hascaptures() being called over and over.

GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/nmap...(no debugging symbols found)...done.
[New LWP 17917]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `nmap -sV <IP_ADDRESS>'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f8e05b3f257 in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
(gdb) bt
#0 0x00007f8e05b3f257 in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#1 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#2 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#3 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#4 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#5 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#6 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#7 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#8 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#9 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#10 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#11 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#12 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#13 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
#14 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
....
#161459 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
......
#354107 0x00007f8e05b3f25c in hascaptures () from /usr/lib/x86_64-linux-gnu/liblua5.2-lpeg.so.2
...

0x00007f8e05b3f253 <+51>: lea 0x8(%rbx),%rdi
=> 0x00007f8e05b3f257 <+55>: callq 0x7f8e05b3f220 <hascaptures>
0x00007f8e05b3f25c <+60>: test %eax,%eax

Revision history for this message
Dan Streetman (ddstreet) wrote :
Download full text (3.8 KiB)

The backtrace start (taken from a patched lua_lpeg, so line numbers won't match with latest released version):

(gdb) bt -40
#523468 0x00007ffff6e4026c in hascaptures (tree=0xd1f57c, tree@entry=0xd1f58c) at lpcode.c:144
#523469 0x00007ffff6e4026c in hascaptures (tree=tree@entry=0xd1f584) at lpcode.c:144
#523470 0x00007ffff6e4026c in hascaptures (tree=0xd1f57c, tree@entry=0xd1f58c) at lpcode.c:144
#523471 0x00007ffff6e4026c in hascaptures (tree=tree@entry=0xd1f584) at lpcode.c:144
#523472 0x00007ffff6e4026c in hascaptures (tree=0xd1f57c, tree@entry=0xd1f58c) at lpcode.c:144
#523473 0x00007ffff6e4026c in hascaptures (tree=tree@entry=0xd1f584) at lpcode.c:144
#523474 0x00007ffff6e4026c in hascaptures (tree=0xd1f57c, tree@entry=0xd1f58c) at lpcode.c:144
#523475 0x00007ffff6e4026c in hascaptures (tree=tree@entry=0xd1f584) at lpcode.c:144
#523476 0x00007ffff6e4026c in hascaptures (tree=0xd1f57c, tree@entry=0xd1f58c) at lpcode.c:144
#523477 0x00007ffff6e4026c in hascaptures (tree=tree@entry=0xd1f584) at lpcode.c:144
#523478 0x00007ffff6e4026c in hascaptures (tree=0xd1f57c, tree@entry=0xd1f58c) at lpcode.c:144
#523479 0x00007ffff6e4026c in hascaptures (tree=tree@entry=0xd1f584) at lpcode.c:144
#523480 0x00007ffff6e4026c in hascaptures (tree=0xd1f57c, tree@entry=0xd1f5b4) at lpcode.c:144
#523481 0x00007ffff6e4026c in hascaptures (tree=tree@entry=0xd1f5ac) at lpcode.c:144
#523482 0x00007ffff6e410a4 in codecapture (fl=0x7ffff6e421c0 <fullset_>, tt=-1, tree=0xd1f5a4, compst=0x7fffffffcf10) at lpcode.c:720
#523483 codegen (compst=compst@entry=0x7fffffffcf10, tree=tree@entry=0xd1f5a4, opt=opt@entry=0, tt=tt@entry=-1, fl=fl@entry=0x7ffff6e421c0 <fullset_>) at lpcode.c:905
#523484 0x00007ffff6e41715 in codegrammar (compst=compst@entry=0x7fffffffcf10, grammar=grammar@entry=0xd1f4c4) at lpcode.c:850
#523485 0x00007ffff6e41023 in codegen (compst=compst@entry=0x7fffffffcf10, tree=tree@entry=0xd1f4c4, opt=opt@entry=0, tt=tt@entry=-1, fl=fl@entry=0x7ffff6e421c0 <fullset_>) at lpcode.c:907
#523486 0x00007ffff6e4188e in compile (L=0x2050cd0, p=0xd1f4b8) at lpcode.c:977
#523487 0x00007ffff6e3fdeb in lp_match (L=0x2050cd0) at lptree.c:1150
#523488 0x00007ffff70508ed in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523489 0x00007ffff705c4ed in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523490 0x00007ffff7050ae0 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523491 0x00007ffff705026f in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523492 0x00007ffff7050cc7 in lua_resume () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523493 0x00007ffff7060f44 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523494 0x00007ffff70612b1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523495 0x00007ffff70508ed in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523496 0x00007ffff705c4ed in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523497 0x00007ffff7050c2e in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523498 0x00007ffff704cccb in lua_callk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#523499 0x00000000004a5036 in run_main (L=0xca0cf0) at nse_main.cc:651
#523500 0x00007ffff70508ed in ?? () from /usr/lib/x86_64-lin...

Read more...

Revision history for this message
Dan Streetman (ddstreet) wrote :

While the lua-lpeg code's careless use of recursion is certainly not good, I'm not sure if it is causing the current problem; I suspect it may be nmap introducting a problem in the tree that causes the infinite recursion. I've applied almost all the patches to bring lua_lpeg up to the bionic version, and it's still reproducable; I'll try with the full bionic lua_lpeg version to make sure the issue is in nmap (or at least, being triggered by xenial version of nmap).

Changed in nmap (Ubuntu Xenial):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → Low
status: New → In Progress
Revision history for this message
Dan Streetman (ddstreet) wrote :

I confirmed that xenial nmap still segfaults when the bionic version of lua-lpeg, so it looks like some commit in nmap between xenial and bionic fixes this, not any change in lua-lpeg.

Revision history for this message
Bryce Harrington (bryce) wrote :

The packaging changes between xenial and bionic don't seem to involve lua-lpeg, and notably the patch 0003-Link-against-lua-lpeg.patch is included in both (the patch is refreshed for lua5.3 in bionic, so the patch isn't identical).

The diff of CHANGELOG between 7.01 and 7.60 doesn't indicate a mention of lua-lpeg or a fix of a recursion error, and none of the mentions of lua fixes seem to match this error. There's a lot of changes between these two versions, though. I'm guessing a bisection search would be the most straightforward way to identify the fix?

ddstreet, when you tested against the bionic lua-lpeg, were you testing with lua5.2 or lua5.3? Presumably you've ruled out lua as a variable?

Victor Tapia (vtapia)
Changed in nmap (Ubuntu Xenial):
assignee: Dan Streetman (ddstreet) → Victor Tapia (vtapia)
Revision history for this message
Victor Tapia (vtapia) wrote :

I think I found the root cause of this issue. 0003-Link-against-lua-lpeg.patch tries to fix a linking error related to the function named luaopen_lpeg(), making nmap use the luaopen_lpeg() in lua-lpeg instead of the local function declared in lpeg.c (which are slightly different). The original linking issue was addressed upstream[1] by setting the function as extern[2] somewhere between 7.0.1 and 7.10, and that's why newer releases do not see this bug. I have a PPA[3] prepared to start testing, replacing 0003-Link-against-lua-lpeg.patch with the upstream fix.

[1] https://github.com/nmap/nmap/issues/237
[2] https://github.com/nmap/nmap/commit/9bcc6c09e22e3a32e8f89a13afee5a9a77b92b62
[3] https://launchpad.net/~vtapia/+archive/ubuntu/sf238253

Victor Tapia (vtapia)
Changed in nmap (Ubuntu Eoan):
assignee: nobody → Victor Tapia (vtapia)
Victor Tapia (vtapia)
no longer affects: nmap (Ubuntu Eoan)
Revision history for this message
Victor Tapia (vtapia) wrote :

# REPRODUCER: Install LXD, make it available over the network and run nmap against its ip:

# lxd init
Do you want to configure a new storage pool (yes/no) [default=yes]? no
Would you like LXD to be available over the network (yes/no) [default=no]? yes
Address to bind LXD to (not including port) [default=all]:
Port to bind LXD to [default=8443]:
Trust password for new clients:
Again:
Do you want to configure the LXD bridge (yes/no) [default=yes]? no
LXD has been successfully configured.

$ sudo netstat -anp | grep 8443
tcp6 0 0 :::8443 :::* LISTEN 817/lxd

$ while true; do nmap -sV localhost -Pn -d 2>&1 || break; done

Starting Nmap 7.01 ( https://nmap.org ) at 2019-10-02 18:33 CEST
PORTS: Using top 1000 ports found open (TCP:1000, UDP:0, SCTP:0)
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
NSE: Using Lua 5.2.
NSE: Arguments from CLI:
NSE: Loaded 35 scripts for scanning.
mass_rdns: Using DNS server 192.168.11.1
Initiating Connect Scan at 18:33
Scanning localhost (127.0.0.1) [1000 ports]
Discovered open port 22/tcp on 127.0.0.1
Discovered open port 8443/tcp on 127.0.0.1
Completed Connect Scan at 18:33, 0.01s elapsed (1000 total ports)
Overall sending rates: 67769.04 packets / s.
Initiating Service scan at 18:33
Scanning 2 services on localhost (127.0.0.1)
Completed Service scan at 18:35, 82.59s elapsed (2 services on 1 host)
NSE: Script scanning 127.0.0.1.
NSE: Starting runlevel 1 (of 1) scan.
Initiating NSE at 18:35
NSE: Starting rpc-grind against localhost (127.0.0.1:8443).
NSE: Starting http-server-header against localhost (127.0.0.1:8443).
Segmentation fault (core dumped)

Revision history for this message
Victor Tapia (vtapia) wrote :

I've been able to finish the analysis of the bug, this is the summary:

- nmap includes an old version of lpeg (0.12 ~Trusty/oldoldstable) in all releases (all files merged in lpeg.c)
- Debian introduced a patch that links nmap's build against an external lua-lpeg lib because lpeg is properly packaged (a hygiene measure according to Debian's maintainer)
- Upstream introduced a patch, available in B+, that fixed a FTBFS regarding lpeg (undefined reference for luaopen_lpeg())
- The version of lua-lpeg in X/B/E has a recursion error
- When both the upstream commit and the external linking patch are available, local lpeg is used

This results in:

- X fails because it uses lua-lpeg (no upstream commit in the build)
- B works because it uses local lpeg (upstream commit available)
- E is a special case in my reproducer: the debian patch removes #include "lpeg.c" so it uses the external lua-lpeg, but works because the scanned service has a fingerprint and avoids the crash. Removing the fingerprint from /usr/share/nmap/nmap-service-probes makes it crash as expected

The best way to fix this bug will be to fix the recursion error in lua-lpeg so nmap would work regardless of the version of lua-lpeg it uses.

Victor Tapia (vtapia)
description: updated
Victor Tapia (vtapia)
no longer affects: nmap (Ubuntu)
no longer affects: nmap (Ubuntu Xenial)
no longer affects: lua-lpeg (Ubuntu Focal)
Revision history for this message
Victor Tapia (vtapia) wrote :
Eric Desrochers (slashd)
Changed in lua-lpeg (Ubuntu):
assignee: nobody → Victor Tapia (vtapia)
status: New → In Progress
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "focal.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Changed in lua-lpeg (Debian):
status: Unknown → New
Eric Desrochers (slashd)
Changed in lua-lpeg (Ubuntu):
importance: Undecided → Critical
importance: Critical → Medium
Revision history for this message
Eric Desrochers (slashd) wrote :

[sts-sponsor]

Sponsored in focal.

# Nitpick:
I have appended the changelog to add the LP bug.

# Upstream project have no vcs, therefore no commit available. Upstream just release tarballs.

# No merge/sync needed. Debian and Ubuntu package are already at same version level.

# Since this is easy to reproduce using the given repro.lua program, I took some time to double-check before final upload:
---

-> With current pkg found in the archive
$ ./repro.lua
Segmentation fault (core dumped)

-> With the just got sponsored pkg
$ ./repro.lua
root@focal:/tmp#

no segfault nor other error ^

# SRU note
As an fyi, for the continuity (SRU), since most versions are identical, please use the following approach:

From:
 ....
 lua-lpeg | 1.0.0-2 | bionic/universe
 lua-lpeg | 1.0.0-2 | disco/universe
 lua-lpeg | 1.0.0-2 | eoan
 lua-lpeg | 1.0.0-2 | focal

To :
 ....
 lua-lpeg | 1.0.0-2ubuntu0.18.04.1 | bionic/universe
 lua-lpeg | 1.0.0-2ubuntu0.19.04.1 | disco/universe
 lua-lpeg | 1.0.0-2ubuntu0.19.10.1 | eoan
 lua-lpeg | 1.0.0-2ubuntu1 | focal

Thanks Victor for your contribution !

- Eric

Eric Desrochers (slashd)
Changed in lua-lpeg (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lua-lpeg - 1.0.0-2ubuntu1

---------------
lua-lpeg (1.0.0-2ubuntu1) focal; urgency=medium

  * d/p/stop-hascaptures-recursion.patch: Fix infinite recursion in
    hascaptures(). (LP: #1580385)

 -- Victor Tapia <email address hidden> Wed, 02 Oct 2019 17:49:19 +0200

Changed in lua-lpeg (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Victor Tapia (vtapia) wrote :
Revision history for this message
Victor Tapia (vtapia) wrote :
Revision history for this message
Victor Tapia (vtapia) wrote :
Revision history for this message
Victor Tapia (vtapia) wrote :
Eric Desrochers (slashd)
Changed in lua-lpeg (Ubuntu Eoan):
assignee: nobody → Victor Tapia (vtapia)
Changed in lua-lpeg (Ubuntu Disco):
assignee: nobody → Victor Tapia (vtapia)
Changed in lua-lpeg (Ubuntu Bionic):
assignee: nobody → Victor Tapia (vtapia)
Changed in lua-lpeg (Ubuntu Xenial):
assignee: nobody → Victor Tapia (vtapia)
status: New → In Progress
Changed in lua-lpeg (Ubuntu Disco):
status: New → In Progress
Changed in lua-lpeg (Ubuntu Bionic):
status: New → In Progress
Changed in lua-lpeg (Ubuntu Xenial):
importance: Undecided → Medium
Changed in lua-lpeg (Ubuntu Disco):
importance: Undecided → Medium
Changed in lua-lpeg (Ubuntu Bionic):
importance: Undecided → Medium
Changed in lua-lpeg (Ubuntu Eoan):
importance: Undecided → Medium
status: New → In Progress
Revision history for this message
Eric Desrochers (slashd) wrote :

Another note on the focal package of lua-lpeg ... (and this also implies to debian) the src package still uses v7 debhelper compat version which is 11 years old and obviously deprecated nowadays.

I have reported a bug against lua-lpeg debian as follows:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944360

If no action from debian, I'll try to spend some time fixing it (if time permit)

I deally, I would like to see lua-lpeg being modernize before we enter the freeze schedule with a modern debhelper version and fixing any relevant lintian report warning.

Revision history for this message
Eric Desrochers (slashd) wrote :

[sts-sponsor]

Sponsored for E, D, B & X. Packages are now waiting in their respectives upload queues for approval in order to start building in -proposed for the testing phase of the SRU.

Thanks again Victor

- Eric

Revision history for this message
Eric Desrochers (slashd) wrote :
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello errors.ubuntu.com, or anyone else affected,

Accepted lua-lpeg into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/lua-lpeg/1.0.0-2ubuntu0.19.10.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 and change the tag from verification-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. 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.

Changed in lua-lpeg (Ubuntu Eoan):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-eoan
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Hello errors.ubuntu.com, or anyone else affected,

Accepted lua-lpeg into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/lua-lpeg/1.0.0-2ubuntu0.19.04.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 and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. 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.

Changed in lua-lpeg (Ubuntu Disco):
status: In Progress → Fix Committed
tags: added: verification-needed-disco
Changed in lua-lpeg (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed-bionic
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Hello errors.ubuntu.com, or anyone else affected,

Accepted lua-lpeg into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/lua-lpeg/1.0.0-2ubuntu0.18.04.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 and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. 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.

Changed in lua-lpeg (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed-xenial
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Hello errors.ubuntu.com, or anyone else affected,

Accepted lua-lpeg into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/lua-lpeg/0.12.2-1ubuntu1 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 and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. 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.

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Also, a small note: in the future I would appreciate a bit more analysis regarding regression potential. It's good to know the overall assessment (like, "low") and the nature of the fix, but for the future it's also good to write down any possible areas where we could anticipate regressions caused by the changes introduced by the bugfix. This requires and additional thought exercise, looking at the patches and trying to figure out what could theoretically go wrong. Bugfixes modify some code, which can accidentally break something - and this is something we'd want to know more about.

Thank you!

Revision history for this message
Victor Tapia (vtapia) wrote :

#VERIFICATION EOAN

Running the following script:

$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"

p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")

- With the current version:

$ dpkg -l|grep lua-lpeg
ii lua-lpeg:amd64 1.0.0-2 amd64 LPeg library for the Lua language

$ ./repro.lua
[1] 4168 segmentation fault (core dumped) ./repro.lua

nmap segfaults too after a few runs (removing the service fingerprint first as mentioned in the comment #11):

$ count=1; while true; do nmap -sV 192.168.1.114 -Pn > /dev/null && ((count+=1)) || break; done; echo $count
7

- With the version in -proposed the script works as expected:

$ dpkg -l | grep lua-lpeg
ii lua-lpeg:amd64 1.0.0-2ubuntu0.19.10.1 amd64 LPeg library for the Lua language

$ ./repro.lua

$ echo $?
0

nmap works too (was manually stopped after 300+ runs):

$ count=1; while true; do nmap -sV 192.168.1.114 -Pn > /dev/null && ((count+=1)) || break; done; echo $count

$ echo $count
383

Revision history for this message
Victor Tapia (vtapia) wrote :

#VERIFICATION DISCO

Running the following script:

$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"

p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")

- With the current version:

$ dpkg -l|grep lua-lpeg
ii lua-lpeg:amd64 1.0.0-2 amd64 LPeg library for the Lua language

$ ./repro.lua
[1] 1119 segmentation fault (core dumped) ./repro.lua

In this case nmap works because it's using an old internal version of lua-lpeg (see comment #11)

- With the version in -proposed the script works as expected:

$ dpkg -l | grep lua-lpeg
ii lua-lpeg:amd64 1.0.0-2ubuntu0.19.04.1 amd64 LPeg library for the Lua language

$ ./repro.lua

$ echo $?
0

Revision history for this message
Victor Tapia (vtapia) wrote :

#VERIFICATION BIONIC

Running the following script:

$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"

p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")

- With the current version:

$ dpkg -l|grep lua-lpeg
ii lua-lpeg:amd64 1.0.0-2 amd64 LPeg library for the Lua language

$ ./repro.lua
Segmentation fault (core dumped)

In this case nmap works because it's using an old internal version of lua-lpeg (see comment #11)

- With the version in -proposed the script works as expected:

$ dpkg -l | grep lua-lpeg
ii lua-lpeg:amd64 1.0.0-2ubuntu0.18.04.1 amd64 LPeg library for the Lua language
$ ./repro.lua
$ echo $?
0

Revision history for this message
Victor Tapia (vtapia) wrote :

#VERIFICATION XENIAL

Running the following script:

$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"

p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")

- With the current version:

$ dpkg -l | grep lua-lpeg
ii lua-lpeg:amd64 0.12.2-1 amd64 LPeg library for the Lua language

$ ./repro.lua
Segmentation fault (core dumped)

nmap segfaults too after a few runs:

$ count=1; while true; do nmap -sV 192.168.1.114 -Pn > /dev/null && ((count+=1)) || break; done; echo $count
Segmentation fault (core dumped)
2

- With the version in -proposed the script works as expected:

$ dpkg -l | grep lua-lpeg
ii lua-lpeg:amd64 0.12.2-1ubuntu1 amd64 LPeg library for the Lua language

$ ./repro.lua
$ echo $?
0

nmap works (manually stopped):

$ count=1; while true; do nmap -sV 192.168.1.114 -Pn > /dev/null && ((count+=1)) || break; done; echo $count
$ echo $count
179

tags: added: verification-done verification-done-bionic verification-done-disco verification-done-eoan verification-done-xenial
removed: verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan verification-needed-xenial
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lua-lpeg - 1.0.0-2ubuntu0.19.10.1

---------------
lua-lpeg (1.0.0-2ubuntu0.19.10.1) eoan; urgency=medium

  * d/p/stop-hascaptures-recursion.patch: Fix infinite recursion in
    hascaptures() (LP: #1580385)

 -- Victor Tapia <email address hidden> Wed, 02 Oct 2019 17:49:19 +0200

Changed in lua-lpeg (Ubuntu Eoan):
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

The verification of the Stable Release Update for lua-lpeg 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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lua-lpeg - 1.0.0-2ubuntu0.19.04.1

---------------
lua-lpeg (1.0.0-2ubuntu0.19.04.1) disco; urgency=medium

  * d/p/stop-hascaptures-recursion.patch: Fix infinite recursion in
    hascaptures() (LP: #1580385)

 -- Victor Tapia <email address hidden> Wed, 02 Oct 2019 17:49:19 +0200

Changed in lua-lpeg (Ubuntu Disco):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lua-lpeg - 1.0.0-2ubuntu0.18.04.1

---------------
lua-lpeg (1.0.0-2ubuntu0.18.04.1) bionic; urgency=medium

  * d/p/stop-hascaptures-recursion.patch: Fix infinite recursion in
    hascaptures() (LP: #1580385)

 -- Victor Tapia <email address hidden> Wed, 02 Oct 2019 17:49:19 +0200

Changed in lua-lpeg (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lua-lpeg - 0.12.2-1ubuntu1

---------------
lua-lpeg (0.12.2-1ubuntu1) xenial; urgency=medium

  * d/p/stop-hascaptures-recursion.patch: Fix infinite recursion in
    hascaptures() (LP: #1580385)

 -- Victor Tapia <email address hidden> Wed, 02 Oct 2019 17:49:19 +0200

Changed in lua-lpeg (Ubuntu Xenial):
status: Fix Committed → Fix Released
Changed in lua-lpeg (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.