kernel/linux.git/net/rfkill, branch v6.12.80

net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer

2025-09-25T09:13:47+00:00

commit b6f56a44e4c1014b08859dcf04ed246500e310e5 upstream. Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") rfkill_find_type() gets called with the possibly uninitialized "const char *type_name;" local variable. On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no "type" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device 2. The stack happened to contain NULL where type_name is stored Fixes: 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") Cc: stable@vger.kernel.org Cc: Heikki Krogerus Signed-off-by: Hans de Goede Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20250913113515.21698-1-hansg@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

net: rfkill: gpio: Add check for clk_enable()

2024-12-05T13:01:57+00:00

[ Upstream commit 8251e7621b25ccdb689f1dd9553b8789e3745ea1 ] Add check for the return value of clk_enable() to catch the potential error. Fixes: 7176ba23f8b5 ("net: rfkill: add generic gpio rfkill driver") Signed-off-by: Mingwei Zheng Signed-off-by: Jiasheng Jiang Link: https://patch.msgid.link/20241108195341.1853080-1-zmw12306@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

[tree-wide] finally take no_llseek out

2024-09-27T15:18:43+00:00

no_llseek had been defined to NULL two years ago, in commit 868941b14441 ("fs: remove no_llseek") To quote that commit, At -rc1 we'll need do a mechanical removal of no_llseek - git grep -l -w no_llseek | grep -v porting.rst | while read i; do sed -i '/\/d' $i done would do it. Unfortunately, that hadn't been done. Linus, could you do that now, so that we could finally put that thing to rest? All instances are of the form .llseek = no_llseek, so it's obviously safe. Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

wifi: rfkill: Correct parameter type for rfkill_set_hw_state_reason()

2024-08-27T08:28:55+00:00

Change type of parameter @reason to enum rfkill_hard_block_reasons for API rfkill_set_hw_state_reason() according to its comments, and all kernel callers have invoked the API with enum type actually. Signed-off-by: Zijun Hu Link: https://patch.msgid.link/20240811-rfkill_fix-v2-1-9050760336f4@quicinc.com Signed-off-by: Johannes Berg

net: rfkill: gpio: Do not load on Lenovo Yoga Tab 3 Pro YT3-X90

2024-08-27T08:28:55+00:00

The Lenovo Yoga Tab 3 Pro YT3-X90 has a non functional "BCM4752" ACPI device, which uses GPIO resources which are actually necessary / used for the sound (codec, speaker amplifier) on the Lenovo Yoga Tab 3 Pro. If the rfkill-gpio driver loads before the sound drivers do the sound drivers fail to load because the GPIOs are already claimed. Add a DMI based deny list with the Lenovo Yoga Tab 3 Pro on there and make rfkill_gpio_probe() exit with -ENODEV for devices on the DMI based deny list. Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20240825131916.6388-1-hdegoede@redhat.com Signed-off-by: Johannes Berg

net: rfkill: Correct return value in invalid parameter case

2024-06-26T08:49:01+00:00

rfkill_set_hw_state_reason() does not return current combined block state when its parameter @reason is invalid, that is wrong according to its comments, fix it by correcting the value returned. Also reformat the WARN while at it. Signed-off-by: Zijun Hu Link: https://patch.msgid.link/1718287476-28227-1-git-send-email-quic_zijuhu@quicinc.com [edit/reformat commit message, remove unneeded variable] Signed-off-by: Johannes Berg

net: rfkill: gpio: Convert to platform remove callback returning void

2024-03-25T14:40:22+00:00

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Reviewed-by: Jeff Johnson Link: https://msgid.link/20240306183538.88777-2-u.kleine-koenig@pengutronix.de Signed-off-by: Johannes Berg

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2023-12-21T21:17:23+00:00

Cross-merge networking fixes after downstream PR. Adjacent changes: drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c 23c93c3b6275 ("bnxt_en: do not map packet buffers twice") 6d1add95536b ("bnxt_en: Modify TX ring indexing logic.") tools/testing/selftests/net/Makefile 2258b666482d ("selftests: add vlan hw filter tests") a0bc96c0cd6e ("selftests: net: verify fq per-band packet limit") Signed-off-by: Paolo Abeni

net: rfkill: gpio: set GPIO direction

2023-12-12T09:14:57+00:00

Fix the undefined usage of the GPIO consumer API after retrieving the GPIO description with GPIO_ASIS. The API documentation mentions that GPIO_ASIS won't set a GPIO direction and requires the user to set a direction before using the GPIO. This can be confirmed on i.MX6 hardware, where rfkill-gpio is no longer able to enabled/disable a device, presumably because the GPIO controller was never configured for the output direction. Fixes: b2f750c3a80b ("net: rfkill: gpio: prevent value glitch during probe") Cc: stable@vger.kernel.org Signed-off-by: Rouven Czerwinski Link: https://msgid.link/20231207075835.3091694-1-r.czerwinski@pengutronix.de Signed-off-by: Johannes Berg

rfkill: return ENOTTY on invalid ioctl

2023-11-24T19:03:59+00:00

For unknown ioctls the correct error is ENOTTY "Inappropriate ioctl for device". ENOSYS as returned before should only be used to indicate that a syscall is not available at all. Signed-off-by: Thomas Weißschuh Reviewed-by: Przemek Kitszel Link: https://lore.kernel.org/r/20231101-rfkill-ioctl-enosys-v1-1-5bf374fabffe@weissschuh.net [in theory this breaks userspace API, but it was discussed and researched, and nothing found relying on the current behaviour] Signed-off-by: Johannes Berg