December 2024 - Linux-stable-mirror

[PATCH v5.10.277] wifi: mac80211: Avoid address calculations via out of bounds array indexing

by Hardik Gohil

From: Kenton Groombridge <concord(a)gentoo.org> [ Upstream commit 2663d0462eb32ae7c9b035300ab6b1523886c718 ] req->n_channels must be set before req->channels[] can be used. This patch fixes one of the issues encountered in [1]. [ 83.964255] UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:364:4 [ 83.964258] index 0 is out of range for type 'struct ieee80211_channel *[]' [...] [ 83.964264] Call Trace: [ 83.964267] <TASK> [ 83.964269] dump_stack_lvl+0x3f/0xc0 [ 83.964274] __ubsan_handle_out_of_bounds+0xec/0x110 [ 83.964278] ieee80211_prep_hw_scan+0x2db/0x4b0 [ 83.964281] __ieee80211_start_scan+0x601/0x990 [ 83.964291] nl80211_trigger_scan+0x874/0x980 [ 83.964295] genl_family_rcv_msg_doit+0xe8/0x160 [ 83.964298] genl_rcv_msg+0x240/0x270 [...] [1] https://bugzilla.kernel.org/show_bug.cgi?id=218810 Co-authored-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Kenton Groombridge <concord(a)gentoo.org> Link: https://msgid.link/20240605152218.236061-1-concord@gentoo.org Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> [Xiangyu: Modified to apply on 6.1.y and 6.6.y] Signed-off-by: Xiangyu Chen <xiangyu.chen(a)windriver.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hardik Gohil <hgohil(a)mvista.com> --- net/mac80211/scan.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c index be5d02c..bcbbb9f 100644 --- a/net/mac80211/scan.c +++ b/net/mac80211/scan.c @@ -351,7 +351,8 @@ static bool ieee80211_prep_hw_scan(struct ieee80211_sub_if_data *sdata) struct cfg80211_scan_request *req; struct cfg80211_chan_def chandef; u8 bands_used = 0; - int i, ielen, n_chans; + int i, ielen; + u32 *n_chans; u32 flags = 0; req = rcu_dereference_protected(local->scan_req, @@ -361,34 +362,34 @@ static bool ieee80211_prep_hw_scan(struct ieee80211_sub_if_data *sdata) return false; if (ieee80211_hw_check(&local->hw, SINGLE_SCAN_ON_ALL_BANDS)) { + local->hw_scan_req->req.n_channels = req->n_channels; + for (i = 0; i < req->n_channels; i++) { local->hw_scan_req->req.channels[i] = req->channels[i]; bands_used |= BIT(req->channels[i]->band); } - - n_chans = req->n_channels; } else { do { if (local->hw_scan_band == NUM_NL80211_BANDS) return false; - n_chans = 0; + n_chans = &local->hw_scan_req->req.n_channels; + *n_chans = 0; for (i = 0; i < req->n_channels; i++) { if (req->channels[i]->band != local->hw_scan_band) continue; - local->hw_scan_req->req.channels[n_chans] = + local->hw_scan_req->req.channels[(*n_chans)++] = req->channels[i]; - n_chans++; + bands_used |= BIT(req->channels[i]->band); } local->hw_scan_band++; - } while (!n_chans); + } while (!*n_chans); } - local->hw_scan_req->req.n_channels = n_chans; ieee80211_prepare_scan_chandef(&chandef, req->scan_width); if (req->flags & NL80211_SCAN_FLAG_MIN_PREQ_CONTENT) -- 2.7.4

8 months, 3 weeks

3
3
0 0

[PATCH] drivers: gpio: gpio-ljca: Initialize num before accessing item in ljca_gpio_config

by Haoyu Li

With the new __counted_by annocation in ljca_gpio_packet, the "num" struct member must be set before accessing the "item" array. Failing to do so will trigger a runtime warning when enabling CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Fixes: 1034cc423f1b ("gpio: update Intel LJCA USB GPIO driver") Signed-off-by: Haoyu Li <lihaoyu499(a)gmail.com> --- drivers/gpio/gpio-ljca.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-ljca.c b/drivers/gpio/gpio-ljca.c index 503d2441c58f..817ecb12d550 100644 --- a/drivers/gpio/gpio-ljca.c +++ b/drivers/gpio/gpio-ljca.c @@ -82,9 +82,9 @@ static int ljca_gpio_config(struct ljca_gpio_dev *ljca_gpio, u8 gpio_id, int ret; mutex_lock(&ljca_gpio->trans_lock); + packet->num = 1; packet->item[0].index = gpio_id; packet->item[0].value = config | ljca_gpio->connect_mode[gpio_id]; - packet->num = 1; ret = ljca_transfer(ljca_gpio->ljca, LJCA_GPIO_CONFIG, (u8 *)packet, struct_size(packet, item, packet->num), NULL, 0); -- 2.34.1

8 months, 3 weeks

3
2
0 0

[PATCH net] net :mana :Request a V2 response version for MANA_QUERY_GF_STAT

by Shradha Gupta

The current requested response version(V1) for MANA_QUERY_GF_STAT query results in STATISTICS_FLAGS_TX_ERRORS_GDMA_ERROR value being set to 0 always. In order to get the correct value for this counter we request the response version to be V2. Cc: stable(a)vger.kernel.org Fixes: e1df5202e879 ("net :mana :Add remaining GDMA stats for MANA to ethtool") Signed-off-by: Shradha Gupta <shradhagupta(a)linux.microsoft.com> --- drivers/net/ethernet/microsoft/mana/mana_en.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index 57ac732e7707..f73848a4feb3 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -2536,6 +2536,7 @@ void mana_query_gf_stats(struct mana_port_context *apc) mana_gd_init_req_hdr(&req.hdr, MANA_QUERY_GF_STAT, sizeof(req), sizeof(resp)); + req.hdr.resp.msg_version = GDMA_MESSAGE_V2; req.req_stats = STATISTICS_FLAGS_RX_DISCARDS_NO_WQE | STATISTICS_FLAGS_RX_ERRORS_VPORT_DISABLED | STATISTICS_FLAGS_HC_RX_BYTES | -- 2.43.0

8 months, 3 weeks

3
2
0 0

[PATCH v2 1/2] ocfs2: Revert "ocfs2: fix the la space leak when unmounting an ocfs2 volume"

by Heming Zhao

This reverts commit dfe6c5692fb5 ("ocfs2: fix the la space leak when unmounting an ocfs2 volume"). In commit dfe6c5692fb5, the commit log "This bug has existed since the initial OCFS2 code." is wrong. The correct introduction commit is 30dd3478c3cd ("ocfs2: correctly use ocfs2_find_next_zero_bit()"). The influence of commit dfe6c5692fb5 is that it provides a correct fix for the latest kernel. however, it shouldn't be pushed to stable branches. Let's use this commit to revert all branches that include dfe6c5692fb5 and use a new fix method to fix commit 30dd3478c3cd. Fixes: dfe6c5692fb5 ("ocfs2: fix the la space leak when unmounting an ocfs2 volume") Signed-off-by: Heming Zhao <heming.zhao(a)suse.com> Cc: <stable(a)vger.kernel.org> --- fs/ocfs2/localalloc.c | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/fs/ocfs2/localalloc.c b/fs/ocfs2/localalloc.c index 8ac42ea81a17..5df34561c551 100644 --- a/fs/ocfs2/localalloc.c +++ b/fs/ocfs2/localalloc.c @@ -1002,25 +1002,6 @@ static int ocfs2_sync_local_to_main(struct ocfs2_super *osb, start = bit_off + 1; } - /* clear the contiguous bits until the end boundary */ - if (count) { - blkno = la_start_blk + - ocfs2_clusters_to_blocks(osb->sb, - start - count); - - trace_ocfs2_sync_local_to_main_free( - count, start - count, - (unsigned long long)la_start_blk, - (unsigned long long)blkno); - - status = ocfs2_release_clusters(handle, - main_bm_inode, - main_bm_bh, blkno, - count); - if (status < 0) - mlog_errno(status); - } - bail: if (status) mlog_errno(status); -- 2.43.0

8 months, 3 weeks

2
1
0 0

[PATCH v4] mtd: diskonchip: Cast an operand to prevent potential overflow

by Gax-c

From: Zichen Xie <zichenxie0106(a)gmail.com> There may be a potential integer overflow issue in inftl_partscan(). parts[0].size is defined as "uint64_t" while mtd->erasesize and ip->firstUnit are defined as 32-bit unsigned integer. The result of the calculation will be limited to 32 bits without correct casting. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zichen Xie <zichenxie0106(a)gmail.com> Cc: stable(a)vger.kernel.org --- v2: Correct "Fixes" tag. v3: Shorten subject and adjust commit log wrapping. v4: Add Cc tag. --- drivers/mtd/nand/raw/diskonchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/diskonchip.c b/drivers/mtd/nand/raw/diskonchip.c index 8db7fc424571..70d6c2250f32 100644 --- a/drivers/mtd/nand/raw/diskonchip.c +++ b/drivers/mtd/nand/raw/diskonchip.c @@ -1098,7 +1098,7 @@ static inline int __init inftl_partscan(struct mtd_info *mtd, struct mtd_partiti (i == 0) && (ip->firstUnit > 0)) { parts[0].name = " DiskOnChip IPL / Media Header partition"; parts[0].offset = 0; - parts[0].size = mtd->erasesize * ip->firstUnit; + parts[0].size = (uint64_t)mtd->erasesize * ip->firstUnit; numparts = 1; } -- 2.34.1

8 months, 3 weeks

2
1
0 0

[PATCH] mtd: onenand: Fix uninitialized retlen in do_otp_read()

by Ivan Stepchenko

The function do_otp_read() does not set the output parameter *retlen, which is expected to contain the number of bytes actually read. As a result, in onenand_otp_walk(), the tmp_retlen variable remains uninitialized after calling do_otp_walk() and used to change the values of the buf, len and retlen variables. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 49dc08eeda70 ("[MTD] [OneNAND] fix numerous races") Cc: stable(a)vger.kernel.org Signed-off-by: Ivan Stepchenko <sid(a)itb.spb.ru> --- drivers/mtd/nand/onenand/onenand_base.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/onenand/onenand_base.c b/drivers/mtd/nand/onenand/onenand_base.c index f66385faf631..0dc2ea4fc857 100644 --- a/drivers/mtd/nand/onenand/onenand_base.c +++ b/drivers/mtd/nand/onenand/onenand_base.c @@ -2923,6 +2923,7 @@ static int do_otp_read(struct mtd_info *mtd, loff_t from, size_t len, ret = ONENAND_IS_4KB_PAGE(this) ? onenand_mlc_read_ops_nolock(mtd, from, &ops) : onenand_read_ops_nolock(mtd, from, &ops); + *retlen = ops.retlen; /* Exit OTP access mode */ this->command(mtd, ONENAND_CMD_RESET, 0, 0); -- 2.34.1

8 months, 3 weeks

2
1
0 0

Re: [PATCH v2] selinux: ignore unknown extended permissions

by Thiébaud Weksteen

On Thu, Dec 5, 2024 at 6:42 PM Christian Göttsche <cgzones(a)googlemail.com> wrote: > > Dec 5, 2024 02:09:39 Thiébaud Weksteen <tweek(a)google.com>: > > > When evaluating extended permissions, ignore unknown permissions instead > > of calling BUG(). This commit ensures that future permissions can be > > added without interfering with older kernels. > > > > Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls") > > Cc: stable(a)vger.kernel.org > > Signed-off-by: Thiébaud Weksteen <tweek(a)google.com> > > - BUG(); > > + pr_warn_once( > > + "SELinux: unknown extended permission (%u) will be ignored\n", > > + node->datum.u.xperms->specified); > > + return; > > } > > What about instead of logging once per boot at access decision time logging once per policyload at parse time, like suggested for patch https://patchwork.kernel.org/project/selinux/patch/20241115133619.114393-11… ? > I agree, warning when the policy is loaded makes more sense. For this particular bug, I am trying to keep the patch to a bare minimum as I intend to backport it to stable kernels (on Android, this is preventing us from deploying a policy compatible with both older and newer kernels). Maybe we could land the first version of this patch (without any warning message), with the understanding that your patch will land soon after?

8 months, 3 weeks

1
0
0 0

Re: [PATCH net-next] tcp: Check space before adding MPTCP options

by Mo Yuanhao

在 2024/12/4 19:01, Matthieu Baerts 写道: > Hi MoYuanhao, > > +Cc MPTCP mailing list. > > (Please cc the MPTCP list next time) > > On 04/12/2024 09:58, MoYuanhao wrote: >> Ensure enough space before adding MPTCP options in tcp_syn_options() >> Added a check to verify sufficient remaining space >> before inserting MPTCP options in SYN packets. >> This prevents issues when space is insufficient. > > Thank you for this patch. I'm surprised we all missed this check, but > yes it is missing. > > As mentioned by Eric in his previous email, please add a 'Fixes' tag. > For bug-fixes, you should also Cc stable and target 'net', not 'net-next': > > Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing > connections") > Cc: stable(a)vger.kernel.org > > > Regarding the code, it looks OK to me, as we did exactly that with > mptcp_synack_options(). In mptcp_established_options(), we pass > 'remaining' because many MPTCP options can be set, but not here. So I > guess that's fine to keep the code like that, especially for the 'net' tree. > > > Also, and linked to Eric's email, did you have an issue with that, or is > it to prevent issues in the future? > > > One last thing, please don’t repost your patches within one 24h period, see: > > https://docs.kernel.org/process/maintainer-netdev.html > > > Because the code is OK to me, and the same patch has already been sent > twice to the netdev ML within a few hours, I'm going to apply this patch > in our MPTCP tree with the suggested modifications. Later on, we will > send it for inclusion in the net tree. > > pw-bot: awaiting-upstream > > (Not sure this pw-bot instruction will work as no net/mptcp/* files have > been modified) > > Cheers, > Matt Hi Matt, Thank you for your feedback! I have made the suggested updates to the patch (version 2): I’ve added the Fixes tag and Cc'd the stable(a)vger.kernel.org list. The target branch has been adjusted to net as per your suggestion. I will make sure to Cc the MPTCP list in future submissions. Regarding your question, this patch was created to prevent potential issues related to insufficient space for MPTCP options in the future. I didn't encounter a specific issue, but it seemed like a necessary safeguard to ensure robustness when handling SYN packets with MPTCP options. Additionally, I have made further optimizations to the patch, which are included in the attached version. I believe it would be more elegant to introduce a new function, mptcp_set_option(), similar to mptcp_set_option_cond(), to handle MPTCP options. This is my first time replying to a message in a Linux mailing list, so if there are any formatting issues or mistakes, please point them out and I will make sure to correct them in future submissions. Thanks again for your review and suggestions. Looking forward to seeing the patch applied to the MPTCP tree and later inclusion in the net tree. Best regards, MoYuanhao

8 months, 3 weeks

4
3
0 0

Hello,are you looking for bags supplier?

by Steven

8 months, 3 weeks

1
0
0 0

[PATCH 1/2] zram: refuse to use zero sized block device as backing device

by Kairui Song

From: Kairui Song <kasong(a)tencent.com> Setting a zero sized block device as backing device is pointless, and one can easily create a recursive loop by setting the uninitialized ZRAM device itself as its own backing device by (zram0 is uninitialized): echo /dev/zram0 > /sys/block/zram0/backing_dev It's definitely a wrong config, and the module will pin itself, kernel should refuse doing so in the first place. By refusing to use zero sized device we avoided misuse cases including this one above. Fixes: 013bf95a83ec ("zram: add interface to specif backing device") Reported-by: Desheng Wu <deshengwu(a)tencent.com> Signed-off-by: Kairui Song <kasong(a)tencent.com> Cc: stable(a)vger.kernel.org --- drivers/block/zram/zram_drv.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 0ca6d55c9917..dd48df5b97c8 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -614,6 +614,12 @@ static ssize_t backing_dev_store(struct device *dev, } nr_pages = i_size_read(inode) >> PAGE_SHIFT; + /* Refuse to use zero sized device (also prevents self reference) */ + if (!nr_pages) { + err = -EINVAL; + goto out; + } + bitmap_sz = BITS_TO_LONGS(nr_pages) * sizeof(long); bitmap = kvzalloc(bitmap_sz, GFP_KERNEL); if (!bitmap) { -- 2.47.0

8 months, 3 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024