Bug 1212839 - LTP test cve-2021-22555 setsockopt08.c fails with ENOENT
Summary: LTP test cve-2021-22555 setsockopt08.c fails with ENOENT
Status: RESOLVED INVALID
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: openSUSE Kernel Bugs
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-06-29 07:31 UTC by Petr Vorel
Modified: 2023-12-12 16:39 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
dmesg on 390x (working) https://openqa.opensuse.org/tests/3380876/file/shutdown_ltp-dmesg.txt (64.69 KB, text/plain)
2023-06-29 07:34 UTC, Petr Vorel
Details
dmesg on x86_64 (failing) https://openqa.opensuse.org/tests/3391862/file/serial0.txt (1.10 MB, text/plain)
2023-06-29 07:36 UTC, Petr Vorel
Details
Test output on x86_64 (failing) https://openqa.opensuse.org/tests/3391862/file/serial_terminal.txt (1.35 MB, text/plain)
2023-06-29 07:38 UTC, Petr Vorel
Details
Test output on s390x (working) https://openqa.opensuse.org/tests/3380876/file/serial_terminal.txt (1.56 MB, text/plain)
2023-06-29 07:40 UTC, Petr Vorel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Vorel 2023-06-29 07:31:02 UTC
LTP test cve-2021-22555 setsockopt08.c fails with ENOENT [1], but it expects EINVAL on mostly all archs on Tumbleweed (all but s390x, i.e. aarch64, ppc64le, x86_64 and x86_64 compiled as 32bit).

The test has been failing for very long time (our history goes to 6.3.2 20230517, but it's failing on my VM with 6.2.12-1-default 20230502).

When test run more times (200x with -i200 [3]) it fails only on first time, the rest happily have EINVAL. And indeed, when verifying manually on VM, only first run fails

dmesg on affected archs contains:
[ 1514.789118][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
[ 1514.792200][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
[ 1514.795209][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
[ 1514.798209][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
[ 1514.801190][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
[ 1514.804092][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
[ 1514.807159][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
[ 1514.810210][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
[ 1514.813257][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
[ 1514.816227][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776

But when running manually I see on first (failing):
[  208.455124] bpfilter: Loaded bpfilter_umh pid 1223
[  208.456650] Started bpfilter

(this is also in openQA jobs, but earlier, triggered by setsockopt03.c, which runs earlier). And x_tables run is reported on later (successful run):
[  221.292549] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776
=> Maybe there is a problem with loading x_tables on these 3 archs

Interestingly x_tables is loaded on all archs, including s390x (which does not fail) and the same dmesg [4]

FYI we stop and disable firewall in openQA install_ltp job (this qcow is then used for LTP tests) [5]:

systemctl --no-pager disable firewalld
Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service".
Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service".
systemctl --no-pager stop firewalld

[1] https://openqa.opensuse.org/tests/3390125#step/setsockopt08/7
[2] https://github.com/linux-test-project/ltp/blob/a564d3e1672e9cd7ac302d597ffa21bf189457dd/testcases/kernel/syscalls/setsockopt/setsockopt08.c#L141
[3] https://openqa.opensuse.org/tests/3391862#step/cve-2021-22555/7
[4] https://openqa.opensuse.org/tests/3380876/file/shutdown_ltp-dmesg.txt
[5] https://openqa.opensuse.org/tests/3391842/file/serial_terminal.txt
Comment 1 Petr Vorel 2023-06-29 07:34:22 UTC
Created attachment 867874 [details]
dmesg on 390x (working) https://openqa.opensuse.org/tests/3380876/file/shutdown_ltp-dmesg.txt
Comment 2 Petr Vorel 2023-06-29 07:36:20 UTC
Created attachment 867875 [details]
dmesg on x86_64 (failing) https://openqa.opensuse.org/tests/3391862/file/serial0.txt
Comment 3 Petr Vorel 2023-06-29 07:38:31 UTC
Created attachment 867876 [details]
Test output on x86_64 (failing) https://openqa.opensuse.org/tests/3391862/file/serial_terminal.txt
Comment 4 Petr Vorel 2023-06-29 07:40:30 UTC
Created attachment 867877 [details]
Test output on s390x (working) https://openqa.opensuse.org/tests/3380876/file/serial_terminal.txt
Comment 5 Petr Vorel 2023-07-18 11:51:40 UTC
@Nicolai, any idea what's wrong with the test?
Comment 6 Richard Palethorpe 2023-09-04 11:09:30 UTC
Yes, this could be caused by the ipt_state module not being loaded. Except that the kernel should load the module and retry.

	match = xt_find_match(nfproto, name, revision);
	if (IS_ERR(match)) {
		request_module("%st_%s", xt_prefix[nfproto], name);
		match = xt_find_match(nfproto, name, revision);
	}

I think xt_find_match is the only function that can return ENOENT before the checks are done which should cause EINVAL.
Comment 7 Richard Palethorpe 2023-10-11 15:00:18 UTC
I had a similar issue on another test and just emitted TCONF if ENOENT is returned. We don't use ip_tables by default on newer products.

Possibly in OpenQA we should use modprobe to load the module.
Comment 8 Petr Vorel 2023-10-12 17:47:44 UTC
(In reply to Richard Palethorpe from comment #7)
> I had a similar issue on another test and just emitted TCONF if ENOENT is
> returned. We don't use ip_tables by default on newer products.

Yes, but the problem here is with Tumbleweed, there is ip_tables module already loaded even before whole testing [1]:

Modules Loaded         af_packet rfkill qrtr snd_hda_codec_generic ledtrig_audio intel_rapl_msr intel_rapl_common kvm_amd ccp hid_generic ppdev snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec kvm snd_hda_core snd_hwdep snd_pcm usbhid irqbypass snd_timer pcspkr tiny_power_button parport_pc virtio_net snd net_failover soundcore i2c_piix4 parport failover button joydev nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse efi_pstore configfs dmi_sysfs ip_tables x_tables crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic gf128mul ghash_clmulni_intel xhci_pci xhci_pci_renesas sr_mod cdrom xhci_hcd sha512_ssse3 ata_generic aesni_intel crypto_simd cryptd ata_piix ahci libahci bochs drm_vram_helper virtio_scsi virtio_blk drm_ttm_helper floppy libata ttm usbcore serio_raw btrfs blake2b_generic libcrc32c crc32c_intel xor raid6_pq sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod scsi_common qemu_fw_cfg virtio_rng

I even tried to call modprobe in the test and result is the same [2]:

setsockopt08 -i 100
...
tst_kconfig.c:87: TINFO: Parsing kernel config '/proc/config.gz'
tst_buffers.c:56: TINFO: Test is using guarded buffers
tst_test.c:1690: TINFO: LTP version: 20230929
tst_test.c:1574: TINFO: Timeout per run is 0h 00m 30s
tst_kernel.c:87: TINFO: uname.machine=x86_64 kernel is 64bit
setsockopt08.c:103: TINFO: The vulnerability was only present in 32-bit compat mode
setsockopt08.c:107: TINFO: Trying to modprobe ip_tables
setsockopt08.c:149: TFAIL: setsockopt(3, IPPROTO_IP, IPT_SO_SET_REPLACE, 0x7faf91a9f800, 1): ENOENT (2)
setsockopt08.c:149: TPASS: setsockopt(3, IPPROTO_IP, IPT_SO_SET_REPLACE, 0x7faf91a9f800, 1): EINVAL (22)
setsockopt08.c:149: TPASS: setsockopt(3, IPPROTO_IP, IPT_SO_SET_REPLACE, 0x7faf91a9f800, 1): EINVAL (22)
setsockopt08.c:149: TPASS: setsockopt(3, IPPROTO_IP, IPT_SO_SET_REPLACE, 


> Possibly in OpenQA we should use modprobe to load the module.

Well, I plan to extend LTP C API to load module. But this will not help here.

[1] https://openqa.opensuse.org/tests/3639088/file/install_ltp-ver_linux_before.txt
[2] https://openqa.opensuse.org/tests/3639088#step/cve-2021-22555/6
Comment 9 Richard Palethorpe 2023-10-13 08:55:08 UTC
(In reply to Petr Vorel from comment #8)
> (In reply to Richard Palethorpe from comment #7)
> > I had a similar issue on another test and just emitted TCONF if ENOENT is
> > returned. We don't use ip_tables by default on newer products.
> 
> Yes, but the problem here is with Tumbleweed, there is ip_tables module
> already loaded even before whole testing [1]:

Ah, the module missing here is ipt_state according to my previous comment.

BTW, I have some issues with how module loading works in LTP, see my comment here:
https://patchwork.ozlabs.org/project/ltp/patch/20231012103916.30712-1-rpalethorpe@suse.com/#3198638
Comment 10 Petr Cervinka 2023-11-30 09:23:55 UTC
LTP issue related to module loading.
Comment 11 Petr Vorel 2023-11-30 09:51:51 UTC
My TODO to fix it: https://progress.opensuse.org/issues/151747
Comment 12 Petr Vorel 2023-12-12 16:39:58 UTC
NOTE: this is actually caused by broken ipt_state module loading due missing  /etc/sysctl.conf (see https://bugzilla.suse.com/show_bug.cgi?id=1217990).