NACK/Cmnt: [SRU][J][PATCH 0/1] CVE-2022-49178

[Edoardo Canepa]

Rejected for the following reasons:

The second hunk is correct. The first one breaks mspro_block_bd_open()
unconditionally on jammy, and makes the reference leak worse rather than
fixing it.

rc is initialised to -ENXIO and the only place it is ever set to a success
value is the "else rc = 0;" this hunk deletes:

     int rc = -ENXIO;
     ...
     if (msb && msb->card) {
         msb->usage_count++;
         if ((mode & FMODE_WRITE) && msb->read_only)
             rc = -EROFS;
         else
             rc = 0;
     }
     ...
     return rc;

After the patch ->open returns -ENXIO on every path, and ms_block_bdops
still installs it. device_add_disk() calls disk_scan_partitions(), which
does blkdev_get_by_dev(disk_devt(disk), FMODE_READ, NULL), so the failure
happens at probe: no partition scan, no mspblkNpM nodes, and every later
open of /dev/mspblkN fails. The card becomes unusable for reading as well
as writing, which is a much wider break than the -EROFS-on-write-open
behaviour being removed.

The leak is worse, not better. usage_count++ survives the hunk, but
blkdev_get_whole() returns as soon as ->open fails, so ->release is never
called and mspro_block_disk_release() never decrements. usage_count is
initialised to 1 in mspro_block_init_disk(), the probe-time open takes it
to 2, and mspro_block_remove() decrements once, so it never reaches 0 and
the kfree(msb)/put_disk() path is unreachable. Every card insertion leaks
the mspro_block_data and the gendisk, with no userspace involvement at
all.

Upstream does not have this problem because 6dab421bfe06 is half of a
pair. Its direct child, 185ed423d189 ("memstick/mspro_block: simplify
refcounting"), deletes mspro_block_bd_open(), mspro_block_bd_release()
and usage_count outright and replaces them with a ->free_disk callback.
Both landed in v5.18-rc1 (~128^2~50 and ~49), so mainline never shipped a
kernel with the dangling rc. This backport would.

The second hunk is fine. msb->read_only is set by h_mspro_block_get_ro()
during mspro_block_init_card(), which probe calls before
mspro_block_init_disk(), so the value is valid at the set_disk_ro() call
site, and set_disk_ro() before device_add_disk() only sets GD_READ_ONLY.
Write rejection without the ->open check is still covered in 5.15 by
submit_bio_checks(), blkdev_write_iter(), blkdev_get_by_path() and the
mount path, all of which go through bdev_read_only().

On 9/8/26 23:17, Cengiz Can via kernel-team wrote:
> https://ubuntu.com/security/CVE-2022-49178
>
> [ Impact ]
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> memstick/mspro_block: fix handling of read-only devices
>
> Use set_disk_ro to propagate the read-only state to the block layer instead of
> checking for it in ->open and leaking a reference in case of a read-only
> device.
>
> The mspro_block driver checked for the read-only state in its ->open
> handler and returned early without releasing the reference it had taken,
> leaking a device reference each time a read-only Memory Stick Pro card was
> opened. Repeated opens can exhaust references and interfere with proper
> device teardown.
>
> [ Fix ]
>
> jammy/linux: backported from 6dab421bfe06
>
> The fix uses set_disk_ro() to communicate the read-only state to the block
> layer at disk registration time, removing the flawed check and reference
> leak in ->open. This tree keeps its existing void-style device_add_disk()
> call, as the additional error-handling context from upstream is not present
> here and is unrelated to this change.
>
> [ Test Plan ]
>
> Build and boot tested.
>
> [ Where Problems Could Occur ]
>
> A bad fix would only affect systems using Memory Stick Pro (MS Pro) media
> through the memstick/mspro_block driver, most notably workflows that mount
> or read write-protected (read-only) MS Pro cards. Systems without such
> hardware, or that never load the mspro_block driver, are not affected.
>
> [ Other Info ]
>
> Kybele flow-v11-21-g0f091652. Reference: 7a7bc36d/v1
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260914/08016a5e/attachment-0001.sig>