From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Johannes Berg <johannes@sipsolutions.net>,
Yuan Tan <yuantan098@gmail.com>, Yifan Wu <yifanwucs@gmail.com>,
Juefei Pu <tomapufckgml@gmail.com>, Xin Liu <bird@lzu.edu.cn>,
stable <stable@kernel.org>,
Johannes Berg <johannes.berg@intel.com>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10.y] net: rfkill: prevent unlimited numbers of rfkill events from being created
Date: Sun, 12 Apr 2026 16:03:08 -0400 [thread overview]
Message-ID: <20260412200308.2406071-1-sashal@kernel.org> (raw)
In-Reply-To: <2026041216-ideology-snowplow-e524@gregkh>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit ea245d78dec594372e27d8c79616baf49e98a4a1 ]
Userspace can create an unlimited number of rfkill events if the system
is so configured, while not consuming them from the rfkill file
descriptor, causing a potential out of memory situation. Prevent this
from bounding the number of pending rfkill events at a "large" number
(i.e. 1000) to prevent abuses like this.
Cc: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/2026033013-disfigure-scroll-e25e@gregkh
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
[ replaced `rfkill_event_ext` with `rfkill_event`, `scoped_guard` with explicit mutex calls, and removed outer `data->mtx` lock in `rfkill_fop_open` to avoid deadlock with new internal locking ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/rfkill/core.c | 40 +++++++++++++++++++++++++++-------------
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 97101c55763d7..7a39454b731a5 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -71,11 +71,14 @@ struct rfkill_int_event {
struct rfkill_event ev;
};
+/* Max rfkill events that can be "in-flight" for one data source */
+#define MAX_RFKILL_EVENT 1000
struct rfkill_data {
struct list_head list;
struct list_head events;
struct mutex mtx;
wait_queue_head_t read_wait;
+ u32 event_count;
bool input_handler;
};
@@ -252,9 +255,12 @@ static void rfkill_global_led_trigger_unregister(void)
}
#endif /* CONFIG_RFKILL_LEDS */
-static void rfkill_fill_event(struct rfkill_event *ev, struct rfkill *rfkill,
- enum rfkill_operation op)
+static int rfkill_fill_event(struct rfkill_int_event *int_ev,
+ struct rfkill *rfkill,
+ struct rfkill_data *data,
+ enum rfkill_operation op)
{
+ struct rfkill_event *ev = &int_ev->ev;
unsigned long flags;
ev->idx = rfkill->idx;
@@ -266,6 +272,16 @@ static void rfkill_fill_event(struct rfkill_event *ev, struct rfkill *rfkill,
ev->soft = !!(rfkill->state & (RFKILL_BLOCK_SW |
RFKILL_BLOCK_SW_PREV));
spin_unlock_irqrestore(&rfkill->lock, flags);
+
+ mutex_lock(&data->mtx);
+ if (data->event_count++ > MAX_RFKILL_EVENT) {
+ data->event_count--;
+ mutex_unlock(&data->mtx);
+ return -ENOSPC;
+ }
+ list_add_tail(&int_ev->list, &data->events);
+ mutex_unlock(&data->mtx);
+ return 0;
}
static void rfkill_send_events(struct rfkill *rfkill, enum rfkill_operation op)
@@ -277,10 +293,10 @@ static void rfkill_send_events(struct rfkill *rfkill, enum rfkill_operation op)
ev = kzalloc(sizeof(*ev), GFP_KERNEL);
if (!ev)
continue;
- rfkill_fill_event(&ev->ev, rfkill, op);
- mutex_lock(&data->mtx);
- list_add_tail(&ev->list, &data->events);
- mutex_unlock(&data->mtx);
+ if (rfkill_fill_event(ev, rfkill, data, op)) {
+ kfree(ev);
+ continue;
+ }
wake_up_interruptible(&data->read_wait);
}
}
@@ -1118,21 +1134,19 @@ static int rfkill_fop_open(struct inode *inode, struct file *file)
init_waitqueue_head(&data->read_wait);
mutex_lock(&rfkill_global_mutex);
- mutex_lock(&data->mtx);
/*
- * start getting events from elsewhere but hold mtx to get
- * startup events added first
+ * start getting events from elsewhere but hold rfkill_global_mutex
+ * to get startup events added first
*/
list_for_each_entry(rfkill, &rfkill_list, node) {
ev = kzalloc(sizeof(*ev), GFP_KERNEL);
if (!ev)
goto free;
- rfkill_fill_event(&ev->ev, rfkill, RFKILL_OP_ADD);
- list_add_tail(&ev->list, &data->events);
+ if (rfkill_fill_event(ev, rfkill, data, RFKILL_OP_ADD))
+ kfree(ev);
}
list_add(&data->list, &rfkill_fds);
- mutex_unlock(&data->mtx);
mutex_unlock(&rfkill_global_mutex);
file->private_data = data;
@@ -1140,7 +1154,6 @@ static int rfkill_fop_open(struct inode *inode, struct file *file)
return stream_open(inode, file);
free:
- mutex_unlock(&data->mtx);
mutex_unlock(&rfkill_global_mutex);
mutex_destroy(&data->mtx);
list_for_each_entry_safe(ev, tmp, &data->events, list)
@@ -1200,6 +1213,7 @@ static ssize_t rfkill_fop_read(struct file *file, char __user *buf,
ret = -EFAULT;
list_del(&ev->list);
+ data->event_count--;
kfree(ev);
out:
mutex_unlock(&data->mtx);
--
2.53.0
prev parent reply other threads:[~2026-04-12 20:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-12 5:16 FAILED: patch "[PATCH] net: rfkill: prevent unlimited numbers of rfkill events from" failed to apply to 5.10-stable tree gregkh
2026-04-12 20:03 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260412200308.2406071-1-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=bird@lzu.edu.cn \
--cc=gregkh@linuxfoundation.org \
--cc=johannes.berg@intel.com \
--cc=johannes@sipsolutions.net \
--cc=stable@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tomapufckgml@gmail.com \
--cc=yifanwucs@gmail.com \
--cc=yuantan098@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox