lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1a5e3ecd-04f5-cdd6-a284-a4c9d0999f11@gmail.com>
Date:   Tue, 27 Sep 2022 19:24:34 +0200
From:   Milan Broz <gmazyland@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Mikulas Patocka <mpatocka@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org, dm-devel@...hat.com,
        Christoph Lameter <cl@...ux.com>
Subject: Re: [dm-devel] [PATCH] kernfs: fix a crash when two processes delete
 the same directory

On 9/27/22 17:37, Greg Kroah-Hartman wrote:
> On Tue, Sep 27, 2022 at 05:22:46PM +0200, Milan Broz wrote:
>> On 9/26/22 14:16, Greg Kroah-Hartman wrote:
>>> On Mon, Sep 26, 2022 at 07:04:52AM -0400, Mikulas Patocka wrote:
>>>> There is a crash when running the cryptsetup testsuite on Fedora Rawhide.
>>>> It can be reproduced by installing Rawhide with the 6.0-rc6 kernel,
>>>> downloading and compiling the cryptsetup repository and running this test
>>>> in a loop for about 15 minuts:
>>>> 	while ./integrity-compat-test; do :; done
>>>>
>>>>    ------------[ cut here ]------------
>>>>    WARNING: CPU: 0 PID: 50087 at fs/kernfs/dir.c:504 __kernfs_remove.part.0+0x26f/0x2b0
>>>>    Modules linked in: crc32_generic loop dm_integrity async_xor async_tx tls isofs uinput snd_seq_dummy snd_hrtimer nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables nfnetlink qrtr sunrpc snd_hda_codec_generic ledtrig_audio snd_hda_intel iTCO_wdt snd_intel_dspcfg intel_pmc_bxt snd_intel_sdw_acpi iTCO_vendor_support snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device joydev snd_pcm i2c_i801 snd_timer pcspkr i2c_smbus virtio_balloon snd lpc_ich soundcore zram virtio_net net_failover virtio_blk serio_raw failover qxl virtio_console drm_ttm_helper ttm ip6_tables ip_tables fuse qemu_fw_cfg
>>>>    Unloaded tainted modules: crc32_pclmul():1 pcc_cpufreq():1 pcc_cpufreq():1 acpi_cpufreq():1 edac_mce_amd():1 pcc_cpufreq():1 acpi_cpufreq():1 edac_mce_amd():1 acpi_cpufreq():1 edac_mce_amd():1 pcc_cpufreq():1 acpi_cpufreq():1 pcc_cpufreq():1 edac_mce_amd():1 edac_mce_amd():1 acpi_cpufreq():1 pcc_cpufreq():1 edac_mce_amd():1 acpi_cpufreq():1 pcc_cpufreq():1 edac_mce_amd():1 acpi_cpufreq():1 pcc_cpufreq():1 edac_mce_amd():1 acpi_cpufreq():1 edac_mce_amd():1 pcc_cpufreq():1 edac_mce_amd():1 acpi_cpufreq():1 pcc_cpufreq():1 edac_mce_amd():1 pcc_cpufreq():1 acpi_cpufreq():1 edac_mce_amd():1 pcc_cpufreq():1 acpi_cpufreq():1 acpi_cpufreq():1
>>>>    CPU: 0 PID: 50087 Comm: integritysetup Not tainted 6.0.0-0.rc6.41.fc38.x86_64 #1
>>>>    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
>>>>    RIP: 0010:__kernfs_remove.part.0+0x26f/0x2b0
>>
>> ...
>>
>>> Can you see if 4abc99652812 ("kernfs: fix use-after-free in
>>> __kernfs_remove") in linux-next fixes this for you or not?  It seems to
>>> be the same issue, as was also reported at:
>>> 	https://lore.kernel.org/r/7f489b14-2fdc-3d91-c87e-6a802bd8592d@I-love.SAKURA.ne.jp
>>
>>
>> I tried it on system where cryptsetup testsuite almost immediately crashed in the integrity test.
>>
>> With the patch in https://lore.kernel.org/r/7f489b14-2fdc-3d91-c87e-6a802bd8592d@I-love.SAKURA.ne.jp
>> it now iterates for some time without any problems, so I think it is fixed.
>>
>> Tested-by: Milan Broz <gmazyland@...il.com>
> 
> Wait, what about the patch that is in linux-next that I pointed to, not
> the one in the email?

Ehm, yes, my mistake.

Now tested 4abc99652812 (it is not visible in any branch anymore, perhaps rebased).

Already running several iterations and no problems, so for the correct patch now:

Tested-by: Milan Broz <gmazyland@...il.com>

Milan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ