RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2159581 - nbdkit command was killed by signal 11 when use luks filter to read LUKS-encrypted disk image
Summary: nbdkit command was killed by signal 11 when use luks filter to read LUKS-encr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: nbdkit
Version: 9.2
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: mxie@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-10 03:20 UTC by mxie@redhat.com
Modified: 2023-05-09 09:06 UTC (History)
12 users (show)

Fixed In Version: nbdkit-1.32.5-4.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-09 07:47:50 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)
vmware-luks-encrypted.png (763.47 KB, image/png)
2023-01-10 03:20 UTC, mxie@redhat.com
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-144592 0 None None None 2023-01-10 03:24:18 UTC
Red Hat Product Errata RHBA-2023:2347 0 None None None 2023-05-09 07:48:11 UTC

Description mxie@redhat.com 2023-01-10 03:20:22 UTC
Created attachment 1936989 [details]
vmware-luks-encrypted.png

Description of problem:
nbdkit command was killed by signal 11 when use luks filter to read LUKS-encrypted disk image 

Version-Release number of selected component (if applicable):
nbdkit-1.32.5-2.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
Scenario1:
1.1 Prepare a LUKSv1-encrypted image which is converted from VMware by v2v, pls refer to screenshot and can copy the disk from http://fileshare.englab.nay.redhat.com/pub/section3/libvirtmanual/mxie/esx6.7-rhel7.8-swap_lvm_luks-redhat123-sda, then use nbdkit luks filer to read the disk image

# nbdkit file esx6.7-rhel7.8-swap_lvm_luks-redhat123-sda --filter=luks passphrase=+/home/diskpw --filter=partition partition=1 --run 'nbdcopy $nbd vmware-luks-disk.img' 
nbdkit: file[1]: error: this disk does not contain a LUKS header
nbdcopy: nbd://localhost:10809: nbd_connect_uri: recv: server disconnected unexpectedly
nbdkit: nbdkit command was killed by signal 11

1.2 Collect the stack trace from the crash
# coredumpctl gdb ;
           PID: 298703 (nbdkit)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Tue 2023-01-10 10:24:40 CST (43s ago)
  Command Line: nbdkit file esx6.7-rhel7.8-swap_lvm_luks-redhat123-sda --filter=luks passphrase=+/home/diskpw --filter=partition partition=1 --run $'nbdcopy $nbd vmware-luks-disk.img'
    Executable: /usr/sbin/nbdkit
 Control Group: /user.slice/user-0.slice/session-23.scope
          Unit: session-23.scope
         Slice: user-0.slice
       Session: 23
     Owner UID: 0 (root)
       Boot ID: b0d9437a66f5443fa217a5fb0c833165
    Machine ID: b56ec58ceb2645e2b57214380e119e04
      Hostname: dell-per740-53.lab.eng.pek2.redhat.com
       Storage: none
       Message: Process 298703 (nbdkit) of user 0 dumped core.

Coredump entry has no core attached (neither internally in the journal nor externally on disk).


Scenario2:

2.1 Prepare a luks encrypted image which is created by qemu-img, then use nbdkit luks filer to read the disk image

# qemu-img create -f luks --object secret,data=LETMEPASS,id=sec0 -o key-secret=sec0 encrypted.img 100M
Formatting 'encrypted.img', fmt=luks size=104857600 key-secret=sec0

# nbdkit file encrypted.img --filter=luks passphrase=LETMEPASS --run 'nbdcopy $nbd data.img'

2.2 Use nbdkit luks filer to read the disk image which is copied by nbdcopy
# nbdkit file data.img --filter=luks passphrase=LETMEPASS --run 'nbdcopy $nbd data-b.img'
nbdkit: file[1]: error: this disk does not contain a LUKS header
nbdcopy: nbd://localhost:10809: nbd_connect_uri: recv: server disconnected unexpectedly
nbdkit: nbdkit command was killed by signal 11

2.3 Collect the stack trace from the crash
# coredumpctl gdb ;
           PID: 298807 (nbdkit)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Tue 2023-01-10 10:27:29 CST (2min 12s ago)
  Command Line: nbdkit file data.img --filter=luks passphrase=LETMEPASS --run $'nbdcopy $nbd data-b.img'
    Executable: /usr/sbin/nbdkit
 Control Group: /user.slice/user-0.slice/session-23.scope
          Unit: session-23.scope
         Slice: user-0.slice
       Session: 23
     Owner UID: 0 (root)
       Boot ID: b0d9437a66f5443fa217a5fb0c833165
    Machine ID: b56ec58ceb2645e2b57214380e119e04
      Hostname: dell-per740-53.lab.eng.pek2.redhat.com
       Storage: none
       Message: Process 298807 (nbdkit) of user 0 dumped core.

Coredump entry has no core attached (neither internally in the journal nor externally on disk).

Actual results:
As above description

Expected results:
luks filter reads LUKS-encrypted disk image successfully

Additional info:

Comment 2 Richard W.M. Jones 2023-01-10 08:50:01 UTC
A note about this step:

> 2.2 Use nbdkit luks filer to read the disk image which is copied by nbdcopy
> # nbdkit file data.img --filter=luks passphrase=LETMEPASS --run 'nbdcopy $nbd data-b.img'

Note that 'data.img' is *not* encrypted.  In step 2.1 you copied
out the unencrypted content into a new unencrypted image.  So
applying the luks filter here will always give an error.

However it should not crash and I have fixed that.

Comment 4 mxie@redhat.com 2023-01-12 02:11:13 UTC
Test the bug with nbdkit-1.32.5-3.el9.x86_64

Steps

1. Prepare a LUKSv1-encrypted image which is converted from VMware by v2v

2. Use nbdkit luks filer to read the disk image

#  nbdkit file esx6.7-rhel7.8-swap_lvm_luks-redhat123-sda --filter=luks passphrase=+/home/diskpw --filter=partition partition=1  --run 'nbdinfo $uri'
nbdkit: file[1]: error: this disk does not contain a LUKS header
nbdkit: file[1]: error: this disk does not contain a LUKS header
nbdinfo: nbd_opt_go: server replied with error to opt_go request: No such file or directory for the default export
nbdinfo: suggestion: to list all exports on the server, use --list
protocol: newstyle-fixed without TLS, using structured packets

Hi Richard,

    Why can't the luks filter open the LUKS encrypted disk image in the previous step? The luks filter man page says that it is compatible with LUKSv1, from the screenshot we can see the luks version of this disk is 1 and luks header is '/dev/mapper/rhel-swap'. Or is above command correct? Please give me some suggestions, thanks

Comment 5 Richard W.M. Jones 2023-01-12 08:19:55 UTC
The error is saying it's not a LUKSv1 disk image.  How was it prepared?

Comment 6 mxie@redhat.com 2023-01-12 08:40:13 UTC
(In reply to Richard W.M. Jones from comment #5)
> The error is saying it's not a LUKSv1 disk image.  How was it prepared?

The partition is encrypted during OS installation, do LUKSv1 disk images have to be created by qemu command?

Comment 7 Richard W.M. Jones 2023-01-12 08:55:43 UTC
The luks filter is being applied to the whole disk (not to a
single partition).  In addition most modern operating systems
use LUKSv2, which this filter does not support.

Although it might be possible to create an encrypted disk which
is compatible with this filter when installing the OS, it's usually
better to think of the luks filter as something which is applied
outside the guest and which the guest is unaware of.  The guest
sees an unencrypted disk at all times.  The host / hypervisor
does the encryption and keeps the key.

This is also how disk encryption is meant to be used with the
qemu tools (which are compatible with the luks filter).

Comment 8 mxie@redhat.com 2023-01-12 10:03:11 UTC
Thanks for explanation, the bug has been fixed because luks filter won't crash when image does not contain a LUKS header

Comment 12 errata-xmlrpc 2023-05-09 07:47:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (nbdkit bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2347


Note You need to log in before you can comment on or make changes to this bug.