staging: rtl8723bs: fix OOB read in rtw_action_frame_parse()grafted

rtw_action_frame_parse() takes a frame_len parameter but never
actually checks it before indexing into the frame body:

	const u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr);
	...
	c = frame_body[0];
	...
	a = frame_body[1];

frame_body already points 24 bytes (sizeof(struct
ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and
frame_body[1] requires frame_len >= 26. A management action frame
shorter than that (e.g. exactly 24 bytes, the minimum a malicious
peer can send) causes a 1-2 byte out-of-bounds read.

This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and
cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass
attacker/user-influenced frame buffers and lengths straight through.

Add the missing length check before frame_body is dereferenced.

Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260728125456.32359-3-meatuni001@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

1 files changed, 234 insertions, 0 deletions

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
new file mode 100644
index 000000000..0421c6208
--- /dev/null
+++ b/drivers/mtd/Kconfig
@@ -0,0 +1,234 @@
+menuconfig MTD
+	tristate "Memory Technology Device (MTD) support"
+	imply NVMEM
+	help
+	  Memory Technology Devices are flash, RAM and similar chips, often
+	  used for solid state file systems on embedded devices. This option
+	  will provide the generic support for MTD drivers to register
+	  themselves with the kernel and for potential users of MTD devices
+	  to enumerate the devices which are present and obtain a handle on
+	  them. It will also allow you to select individual drivers for
+	  particular hardware and users of MTD devices. If unsure, say N.
+
+if MTD
+
+config MTD_TESTS
+	tristate "MTD tests support (DANGEROUS)"
+	depends on m
+	help
+	  This option includes various MTD tests into compilation. The tests
+	  should normally be compiled as kernel modules. The modules perform
+	  various checks and verifications when loaded.
+
+	  WARNING: some of the tests will ERASE entire MTD device which they
+	  test. Do not use these tests unless you really know what you do.
+
+menu "Partition parsers"
+source "drivers/mtd/parsers/Kconfig"
+endmenu
+
+comment "User Modules And Translation Layers"
+
+#
+# MTD block device support is select'ed if needed
+#
+config MTD_BLKDEVS
+	tristate
+
+config MTD_BLOCK
+	tristate "Caching block device access to MTD devices"
+	depends on BLOCK
+	select MTD_BLKDEVS
+	help
+	  Although most flash chips have an erase size too large to be useful
+	  as block devices, it is possible to use MTD devices which are based
+	  on RAM chips in this manner. This block device is a user of MTD
+	  devices performing that function.
+
+	  Note that mounting a JFFS2 filesystem doesn't require using mtdblock.
+	  It's possible to mount a rootfs using the MTD device on the "root="
+	  bootargs as "root=mtd2" or "root=mtd:name_of_device".
+
+	  Later, it may be extended to perform read/erase/modify/write cycles
+	  on flash chips to emulate a smaller block size. Needless to say,
+	  this is very unsafe, but could be useful for file systems which are
+	  almost never written to.
+
+	  You do not need this option for use with the DiskOnChip devices. For
+	  those, enable NFTL support (CONFIG_NFTL) instead.
+
+config MTD_BLOCK_RO
+	tristate "Readonly block device access to MTD devices"
+	depends on MTD_BLOCK!=y && BLOCK
+	select MTD_BLKDEVS
+	help
+	  This allows you to mount read-only file systems (such as cramfs)
+	  from an MTD device, without the overhead (and danger) of the caching
+	  driver.
+
+	  You do not need this option for use with the DiskOnChip devices. For
+	  those, enable NFTL support (CONFIG_NFTL) instead.
+
+comment "Note that in some cases UBI block is preferred. See MTD_UBI_BLOCK."
+	depends on MTD_BLOCK || MTD_BLOCK_RO
+
+config FTL
+	tristate "FTL (Flash Translation Layer) support"
+	depends on BLOCK
+	select MTD_BLKDEVS
+	help
+	  This provides support for the original Flash Translation Layer which
+	  is part of the PCMCIA specification. It uses a kind of pseudo-
+	  file system on a flash device to emulate a block device with
+	  512-byte sectors, on top of which you put a 'normal' file system.
+
+	  You may find that the algorithms used in this code are patented
+	  unless you live in the Free World where software patents aren't
+	  legal - in the USA you are only permitted to use this on PCMCIA
+	  hardware, although under the terms of the GPL you're obviously
+	  permitted to copy, modify and distribute the code as you wish. Just
+	  not use it.
+
+config NFTL
+	tristate "NFTL (NAND Flash Translation Layer) support"
+	depends on BLOCK
+	select MTD_BLKDEVS
+	help
+	  This provides support for the NAND Flash Translation Layer which is
+	  used on M-Systems' DiskOnChip devices. It uses a kind of pseudo-
+	  file system on a flash device to emulate a block device with
+	  512-byte sectors, on top of which you put a 'normal' file system.
+
+	  You may find that the algorithms used in this code are patented
+	  unless you live in the Free World where software patents aren't
+	  legal - in the USA you are only permitted to use this on DiskOnChip
+	  hardware, although under the terms of the GPL you're obviously
+	  permitted to copy, modify and distribute the code as you wish. Just
+	  not use it.
+
+config NFTL_RW
+	bool "Write support for NFTL"
+	depends on NFTL
+	help
+	  Support for writing to the NAND Flash Translation Layer, as used
+	  on the DiskOnChip.
+
+config INFTL
+	tristate "INFTL (Inverse NAND Flash Translation Layer) support"
+	depends on BLOCK
+	select MTD_BLKDEVS
+	help
+	  This provides support for the Inverse NAND Flash Translation
+	  Layer which is used on M-Systems' newer DiskOnChip devices. It
+	  uses a kind of pseudo-file system on a flash device to emulate
+	  a block device with 512-byte sectors, on top of which you put
+	  a 'normal' file system.
+
+	  You may find that the algorithms used in this code are patented
+	  unless you live in the Free World where software patents aren't
+	  legal - in the USA you are only permitted to use this on DiskOnChip
+	  hardware, although under the terms of the GPL you're obviously
+	  permitted to copy, modify and distribute the code as you wish. Just
+	  not use it.
+
+config RFD_FTL
+	tristate "Resident Flash Disk (Flash Translation Layer) support"
+	depends on BLOCK
+	select MTD_BLKDEVS
+	help
+	  This provides support for the flash translation layer known
+	  as the Resident Flash Disk (RFD), as used by the Embedded BIOS
+	  of General Software. There is a blurb at:
+
+		http://www.gensw.com/pages/prod/bios/rfd.htm
+
+config SSFDC
+	tristate "NAND SSFDC (SmartMedia) read only translation layer"
+	depends on BLOCK
+	select MTD_BLKDEVS
+	help
+	  This enables read only access to SmartMedia formatted NAND
+	  flash. You can mount it with FAT file system.
+
+config SM_FTL
+	tristate "SmartMedia/xD new translation layer"
+	depends on BLOCK
+	select MTD_BLKDEVS
+	select MTD_NAND_CORE
+	select MTD_NAND_ECC_SW_HAMMING
+	help
+	  This enables EXPERIMENTAL R/W support for SmartMedia/xD
+	  FTL (Flash translation layer).
+	  Write support is only lightly tested, therefore this driver
+	  isn't recommended to use with valuable data (anyway if you have
+	  valuable data, do backups regardless of software/hardware you
+	  use, because you never know what will eat your data...)
+	  If you only need R/O access, you can use older R/O driver
+	  (CONFIG_SSFDC)
+
+config MTD_OOPS
+	tristate "Log panic/oops to an MTD buffer"
+	help
+	  This enables panic and oops messages to be logged to a circular
+	  buffer in a flash partition where it can be read back at some
+	  later point.
+
+config MTD_PSTORE
+	tristate "Log panic/oops to an MTD buffer based on pstore"
+	depends on PSTORE_BLK
+	help
+	  This enables panic and oops messages to be logged to a circular
+	  buffer in a flash partition where it can be read back as files after
+	  mounting pstore filesystem.
+
+	  If unsure, say N.
+
+config MTD_SWAP
+	tristate "Swap on MTD device support"
+	depends on MTD && SWAP
+	select MTD_BLKDEVS
+	help
+	  Provides volatile block device driver on top of mtd partition
+	  suitable for swapping.  The mapping of written blocks is not saved.
+	  The driver provides wear leveling by storing erase counter into the
+	  OOB.
+
+config MTD_PARTITIONED_MASTER
+	bool "Retain master device when partitioned"
+	default n
+	depends on MTD
+	help
+	  For historical reasons, by default, either a master is present or
+	  several partitions are present, but not both. The concern was that
+	  data listed in multiple partitions was dangerous; however, SCSI does
+	  this and it is frequently useful for applications. This config option
+	  leaves the master in even if the device is partitioned. It also makes
+	  the parent of the partition device be the master device, rather than
+	  what lies behind the master.
+
+config MTD_VIRT_CONCAT
+	bool "Virtual concatenated MTD devices"
+	depends on MTD_PARTITIONED_MASTER
+	help
+	  The driver enables the creation of virtual MTD device by
+	  concatenating multiple physical MTD devices into a single
+	  entity. This allows for the creation of partitions larger than
+	  the individual physical chips, extending across chip boundaries.
+
+source "drivers/mtd/chips/Kconfig"
+
+source "drivers/mtd/maps/Kconfig"
+
+source "drivers/mtd/devices/Kconfig"
+
+source "drivers/mtd/nand/Kconfig"
+
+source "drivers/mtd/lpddr/Kconfig"
+
+source "drivers/mtd/spi-nor/Kconfig"
+
+source "drivers/mtd/ubi/Kconfig"
+
+source "drivers/mtd/hyperbus/Kconfig"
+
+endif # MTD