From: Greg Kroah-Hartman Date: Sat, 18 Feb 2023 08:04:01 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v4.14.306~50 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d5ffe62a8ab3833dae64d6d522f2a6dab7b6802d;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: alsa-hda-conexant-add-a-new-hda-codec-sn6180.patch hugetlb-check-for-undefined-shift-on-32-bit-architectures.patch mmc-sdio-fix-possible-resource-leaks-in-some-error-paths.patch --- diff --git a/queue-4.14/alsa-hda-conexant-add-a-new-hda-codec-sn6180.patch b/queue-4.14/alsa-hda-conexant-add-a-new-hda-codec-sn6180.patch new file mode 100644 index 00000000000..4707920a3c8 --- /dev/null +++ b/queue-4.14/alsa-hda-conexant-add-a-new-hda-codec-sn6180.patch @@ -0,0 +1,31 @@ +From 18d7e16c917a08f08778ecf2b780d63648d5d923 Mon Sep 17 00:00:00 2001 +From: Bo Liu +Date: Thu, 9 Feb 2023 10:13:48 +0800 +Subject: ALSA: hda/conexant: add a new hda codec SN6180 + +From: Bo Liu + +commit 18d7e16c917a08f08778ecf2b780d63648d5d923 upstream. + +The current kernel does not support the SN6180 codec chip. +Add the SN6180 codec configuration item to kernel. + +Signed-off-by: Bo Liu +Cc: +Link: https://lore.kernel.org/r/1675908828-1012-1-git-send-email-bo.liu@senarytech.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_conexant.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_conexant.c ++++ b/sound/pci/hda/patch_conexant.c +@@ -1136,6 +1136,7 @@ static const struct hda_device_id snd_hd + HDA_CODEC_ENTRY(0x14f11f86, "CX8070", patch_conexant_auto), + HDA_CODEC_ENTRY(0x14f12008, "CX8200", patch_conexant_auto), + HDA_CODEC_ENTRY(0x14f120d0, "CX11970", patch_conexant_auto), ++ HDA_CODEC_ENTRY(0x14f120d1, "SN6180", patch_conexant_auto), + HDA_CODEC_ENTRY(0x14f15045, "CX20549 (Venice)", patch_conexant_auto), + HDA_CODEC_ENTRY(0x14f15047, "CX20551 (Waikiki)", patch_conexant_auto), + HDA_CODEC_ENTRY(0x14f15051, "CX20561 (Hermosa)", patch_conexant_auto), diff --git a/queue-4.14/hugetlb-check-for-undefined-shift-on-32-bit-architectures.patch b/queue-4.14/hugetlb-check-for-undefined-shift-on-32-bit-architectures.patch new file mode 100644 index 00000000000..b11494d3b3c --- /dev/null +++ b/queue-4.14/hugetlb-check-for-undefined-shift-on-32-bit-architectures.patch @@ -0,0 +1,63 @@ +From ec4288fe63966b26d53907212ecd05dfa81dd2cc Mon Sep 17 00:00:00 2001 +From: Mike Kravetz +Date: Wed, 15 Feb 2023 17:35:42 -0800 +Subject: hugetlb: check for undefined shift on 32 bit architectures + +From: Mike Kravetz + +commit ec4288fe63966b26d53907212ecd05dfa81dd2cc upstream. + +Users can specify the hugetlb page size in the mmap, shmget and +memfd_create system calls. This is done by using 6 bits within the flags +argument to encode the base-2 logarithm of the desired page size. The +routine hstate_sizelog() uses the log2 value to find the corresponding +hugetlb hstate structure. Converting the log2 value (page_size_log) to +potential hugetlb page size is the simple statement: + + 1UL << page_size_log + +Because only 6 bits are used for page_size_log, the left shift can not be +greater than 63. This is fine on 64 bit architectures where a long is 64 +bits. However, if a value greater than 31 is passed on a 32 bit +architecture (where long is 32 bits) the shift will result in undefined +behavior. This was generally not an issue as the result of the undefined +shift had to exactly match hugetlb page size to proceed. + +Recent improvements in runtime checking have resulted in this undefined +behavior throwing errors such as reported below. + +Fix by comparing page_size_log to BITS_PER_LONG before doing shift. + +Link: https://lkml.kernel.org/r/20230216013542.138708-1-mike.kravetz@oracle.com +Link: https://lore.kernel.org/lkml/CA+G9fYuei_Tr-vN9GS7SfFyU1y9hNysnf=PB7kT0=yv4MiPgVg@mail.gmail.com/ +Fixes: 42d7395feb56 ("mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB") +Signed-off-by: Mike Kravetz +Reported-by: Naresh Kamboju +Reviewed-by: Jesper Juhl +Acked-by: Muchun Song +Tested-by: Linux Kernel Functional Testing +Tested-by: Naresh Kamboju +Cc: Anders Roxell +Cc: Andi Kleen +Cc: Sasha Levin +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/hugetlb.h | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/include/linux/hugetlb.h ++++ b/include/linux/hugetlb.h +@@ -395,7 +395,10 @@ static inline struct hstate *hstate_size + if (!page_size_log) + return &default_hstate; + +- return size_to_hstate(1UL << page_size_log); ++ if (page_size_log < BITS_PER_LONG) ++ return size_to_hstate(1UL << page_size_log); ++ ++ return NULL; + } + + static inline struct hstate *hstate_vma(struct vm_area_struct *vma) diff --git a/queue-4.14/mmc-sdio-fix-possible-resource-leaks-in-some-error-paths.patch b/queue-4.14/mmc-sdio-fix-possible-resource-leaks-in-some-error-paths.patch new file mode 100644 index 00000000000..000cdd02ffe --- /dev/null +++ b/queue-4.14/mmc-sdio-fix-possible-resource-leaks-in-some-error-paths.patch @@ -0,0 +1,127 @@ +From 605d9fb9556f8f5fb4566f4df1480f280f308ded Mon Sep 17 00:00:00 2001 +From: Yang Yingliang +Date: Mon, 30 Jan 2023 20:58:08 +0800 +Subject: mmc: sdio: fix possible resource leaks in some error paths + +From: Yang Yingliang + +commit 605d9fb9556f8f5fb4566f4df1480f280f308ded upstream. + +If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can +not release the resources, because the sdio function is not presented +in these two cases, it won't call of_node_put() or put_device(). + +To fix these leaks, make sdio_func_present() only control whether +device_del() needs to be called or not, then always call of_node_put() +and put_device(). + +In error case in sdio_init_func(), the reference of 'card->dev' is +not get, to avoid redundant put in sdio_free_func_cis(), move the +get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), +it can keep the get/put function be balanced. + +Without this patch, while doing fault inject test, it can get the +following leak reports, after this fix, the leak is gone. + +unreferenced object 0xffff888112514000 (size 2048): + comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) + hex dump (first 32 bytes): + 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... + 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... + backtrace: + [<000000009e5931da>] kmalloc_trace+0x21/0x110 + [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] + [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] + [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] + [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] + +unreferenced object 0xffff888112511000 (size 2048): + comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) + hex dump (first 32 bytes): + 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... + 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... + backtrace: + [<000000009e5931da>] kmalloc_trace+0x21/0x110 + [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] + [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] + [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] + +Fixes: 3d10a1ba0d37 ("sdio: fix reference counting in sdio_remove_func()") +Signed-off-by: Yang Yingliang +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230130125808.3471254-1-yangyingliang@huawei.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/sdio_bus.c | 17 ++++++++++++++--- + drivers/mmc/core/sdio_cis.c | 12 ------------ + 2 files changed, 14 insertions(+), 15 deletions(-) + +--- a/drivers/mmc/core/sdio_bus.c ++++ b/drivers/mmc/core/sdio_bus.c +@@ -267,6 +267,12 @@ static void sdio_release_func(struct dev + if (!(func->card->quirks & MMC_QUIRK_NONSTD_SDIO)) + sdio_free_func_cis(func); + ++ /* ++ * We have now removed the link to the tuples in the ++ * card structure, so remove the reference. ++ */ ++ put_device(&func->card->dev); ++ + kfree(func->info); + kfree(func->tmpbuf); + kfree(func); +@@ -297,6 +303,12 @@ struct sdio_func *sdio_alloc_func(struct + + device_initialize(&func->dev); + ++ /* ++ * We may link to tuples in the card structure, ++ * we need make sure we have a reference to it. ++ */ ++ get_device(&func->card->dev); ++ + func->dev.parent = &card->dev; + func->dev.bus = &sdio_bus_type; + func->dev.release = sdio_release_func; +@@ -350,10 +362,9 @@ int sdio_add_func(struct sdio_func *func + */ + void sdio_remove_func(struct sdio_func *func) + { +- if (!sdio_func_present(func)) +- return; ++ if (sdio_func_present(func)) ++ device_del(&func->dev); + +- device_del(&func->dev); + of_node_put(func->dev.of_node); + put_device(&func->dev); + } +--- a/drivers/mmc/core/sdio_cis.c ++++ b/drivers/mmc/core/sdio_cis.c +@@ -388,12 +388,6 @@ int sdio_read_func_cis(struct sdio_func + return ret; + + /* +- * Since we've linked to tuples in the card structure, +- * we must make sure we have a reference to it. +- */ +- get_device(&func->card->dev); +- +- /* + * Vendor/device id is optional for function CIS, so + * copy it from the card structure as needed. + */ +@@ -418,11 +412,5 @@ void sdio_free_func_cis(struct sdio_func + } + + func->tuples = NULL; +- +- /* +- * We have now removed the link to the tuples in the +- * card structure, so remove the reference. +- */ +- put_device(&func->card->dev); + } + diff --git a/queue-4.14/series b/queue-4.14/series index 2fbfd6a8f5b..8eb71fd49e2 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -36,3 +36,6 @@ net-rose-fix-to-not-accept-on-connected-socket.patch nvme-fc-fix-a-missing-queue-put-in-nvmet_fc_ls_creat.patch aio-fix-mremap-after-fork-null-deref.patch revert-x86-fpu-use-_alignof-to-avoid-undefined-behavior-in-type_align.patch +mmc-sdio-fix-possible-resource-leaks-in-some-error-paths.patch +alsa-hda-conexant-add-a-new-hda-codec-sn6180.patch +hugetlb-check-for-undefined-shift-on-32-bit-architectures.patch