URFkill fails to read RFKILL events with latest kernel

[William Wilson]

The kernel has added a byte to the rfkill event struct to account for a possible reason field. See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=14486c82612a177cb910980c70ba900827ca0894

urfkill is checking to make sure the rfkill event is exactly 8 bytes, and therefore failing when the reason field is included.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Fix RFKILL_EVENT_SIZE_V1 check" 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.]

[Launchpad Janitor (janitor)]

This bug was fixed in the package urfkill - 0.6.0~20150318.103828.5539c0d.1-0ubuntu9

---------------
urfkill (0.6.0~20150318.103828.5539c0d.1-0ubuntu9) hirsute; urgency=medium

  * Allow extra byte in rfkill event struct. This is related to a kernel
    change with commit id 14486c82612a177cb910980c70ba900827ca0894. The
    new byte was added to track the reason for rfkill events. (LP: #1922117)

 -- William 'jawn-smith' Wilson <email address hidden> Wed, 31 Mar 2021 12:50:00 -0500

[William Wilson (jawn-smith)]

This bug is currently not present in The focal HWE kernel 5.11, but now that the kernel team PPA has a 5.13 HWE kernel available I will try to recreate this bug and SRU it if successful.

[William Wilson (jawn-smith)]

This bug will not exist in hwe kernels 5.11 or 5.13. Both of those kernels use a separate rfkill_event and rfkill_event_ext struct with the following explanation:

/**
 * DOC: Extensibility
 *
 * Originally, we had planned to allow backward and forward compatible
 * changes by just adding fields at the end of the structure that are
 * then not reported on older kernels on read(), and not written to by
 * older kernels on write(), with the kernel reporting the size it did
 * accept as the result.
 *
 * This would have allowed userspace to detect on read() and write()
 * which kernel structure version it was dealing with, and if was just
 * recompiled it would have gotten the new fields, but obviously not
 * accessed them, but things should've continued to work.
 *
 * Unfortunately, while actually exercising this mechanism to add the
 * hard block reasons field, we found that userspace (notably systemd)
 * did all kinds of fun things not in line with this scheme:
 *
 * 1. treat the (expected) short writes as an error;
 * 2. ask to read sizeof(struct rfkill_event) but then compare the
 * actual return value to RFKILL_EVENT_SIZE_V1 and treat any
 * mismatch as an error.
 *
 * As a consequence, just recompiling with a new struct version caused
 * things to no longer work correctly on old and new kernels.
 *
 * Hence, we've rolled back &struct rfkill_event to the original version
 * and added &struct rfkill_event_ext. This effectively reverts to the
 * old behaviour for all userspace, unless it explicitly opts in to the
 * rules outlined here by using the new &struct rfkill_event_ext.
 *
 * Userspace using &struct rfkill_event_ext must adhere to the following
 * rules
 *
 * 1. accept short writes, optionally using them to detect that it's
 * running on an older kernel;
 * 2. accept short reads, knowing that this means it's running on an
 * older kernel;
 * 3. treat reads that are as long as requested as acceptable, not
 * checking against RFKILL_EVENT_SIZE_V1 or such.
 */

This preserves backwards compatibility and therefore does not result in the bug seen previously.