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 6.1.y 4/4] net: rfkill: prevent unlimited numbers of rfkill events from being created
Date: Sun, 12 Apr 2026 08:55:17 -0400 [thread overview]
Message-ID: <20260412125517.2219007-4-sashal@kernel.org> (raw)
In-Reply-To: <20260412125517.2219007-1-sashal@kernel.org>
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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/rfkill/core.c | 35 ++++++++++++++++++++++++-----------
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 7ec100adf5945..7a995e7a491b5 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -73,11 +73,14 @@ struct rfkill_int_event {
struct rfkill_event_ext 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;
u8 max_size;
};
@@ -255,10 +258,12 @@ static void rfkill_global_led_trigger_unregister(void)
}
#endif /* CONFIG_RFKILL_LEDS */
-static void rfkill_fill_event(struct rfkill_event_ext *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_ext *ev = &int_ev->ev;
unsigned long flags;
ev->idx = rfkill->idx;
@@ -271,6 +276,15 @@ static void rfkill_fill_event(struct rfkill_event_ext *ev,
RFKILL_BLOCK_SW_PREV));
ev->hard_block_reasons = rfkill->hard_block_reasons;
spin_unlock_irqrestore(&rfkill->lock, flags);
+
+ scoped_guard(mutex, &data->mtx) {
+ if (data->event_count++ > MAX_RFKILL_EVENT) {
+ data->event_count--;
+ return -ENOSPC;
+ }
+ list_add_tail(&int_ev->list, &data->events);
+ }
+ return 0;
}
static void rfkill_send_events(struct rfkill *rfkill, enum rfkill_operation op)
@@ -282,10 +296,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);
}
}
@@ -1190,10 +1204,8 @@ static int rfkill_fop_open(struct inode *inode, struct file *file)
if (!ev)
goto free;
rfkill_sync(rfkill);
- rfkill_fill_event(&ev->ev, rfkill, RFKILL_OP_ADD);
- mutex_lock(&data->mtx);
- list_add_tail(&ev->list, &data->events);
- mutex_unlock(&data->mtx);
+ if (rfkill_fill_event(ev, rfkill, data, RFKILL_OP_ADD))
+ kfree(ev);
}
list_add(&data->list, &rfkill_fds);
mutex_unlock(&rfkill_global_mutex);
@@ -1263,6 +1275,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 12:55 UTC|newest]
Thread overview: 5+ 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 6.1-stable tree gregkh
2026-04-12 12:55 ` [PATCH 6.1.y 1/4] rfkill: Use sysfs_emit() to instead of sprintf() Sasha Levin
2026-04-12 12:55 ` [PATCH 6.1.y 2/4] rfkill: sync before userspace visibility/changes Sasha Levin
2026-04-12 12:55 ` [PATCH 6.1.y 3/4] net: rfkill: reduce data->mtx scope in rfkill_fop_open Sasha Levin
2026-04-12 12:55 ` 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=20260412125517.2219007-4-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