- Linux-stable-mirror - lists.linaro.org

[merged mm-nonmm-stable] squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: Squashfs: reject negative file sizes in squashfs_read_inode() has been removed from the -mm tree. Its filename was squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch This patch was dropped because it was merged into the mm-nonmm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Phillip Lougher <phillip(a)squashfs.org.uk> Subject: Squashfs: reject negative file sizes in squashfs_read_inode() Date: Fri, 26 Sep 2025 22:59:35 +0100 Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip(a)squashfs.org.uk: only need to check 64 bit quantity] Link: https://lkml.kernel.org/r/20250926222305.110103-1-phillip@squashfs.org.uk Link: https://lkml.kernel.org/r/20250926215935.107233-1-phillip@squashfs.org.uk Fixes: 6545b246a2c8 ("Squashfs: inode operations") Signed-off-by: Phillip Lougher <phillip(a)squashfs.org.uk> Reported-by: syzbot+f754e01116421e9754b9(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68d580e5.a00a0220.303701.0019.GAE@google.com/ Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/squashfs/inode.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/fs/squashfs/inode.c~squashfs-reject-negative-file-sizes-in-squashfs_read_inode +++ a/fs/squashfs/inode.c @@ -197,6 +197,10 @@ int squashfs_read_inode(struct inode *in goto failed_read; inode->i_size = le64_to_cpu(sqsh_ino->file_size); + if (inode->i_size < 0) { + err = -EINVAL; + goto failed_read; + } frag = le32_to_cpu(sqsh_ino->fragment); if (frag != SQUASHFS_INVALID_FRAG) { /* _ Patches currently in -mm which might be from phillip(a)squashfs.org.uk are

2 months, 2 weeks

1
0
0 0

[merged mm-nonmm-stable] lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: lib/genalloc: fix device leak in of_gen_pool_get() has been removed from the -mm tree. Its filename was lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch This patch was dropped because it was merged into the mm-nonmm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Johan Hovold <johan(a)kernel.org> Subject: lib/genalloc: fix device leak in of_gen_pool_get() Date: Wed, 24 Sep 2025 10:02:07 +0200 Make sure to drop the reference taken when looking up the genpool platform device in of_gen_pool_get() before returning the pool. Note that holding a reference to a device does typically not prevent its devres managed resources from being released so there is no point in keeping the reference. Link: https://lkml.kernel.org/r/20250924080207.18006-1-johan@kernel.org Fixes: 9375db07adea ("genalloc: add devres support, allow to find a managed pool by device") Signed-off-by: Johan Hovold <johan(a)kernel.org> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Vladimir Zapolskiy <vz(a)mleia.com> Cc: <stable(a)vger.kernel.org> [3.10+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/genalloc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/lib/genalloc.c~lib-genalloc-fix-device-leak-in-of_gen_pool_get +++ a/lib/genalloc.c @@ -899,8 +899,11 @@ struct gen_pool *of_gen_pool_get(struct if (!name) name = of_node_full_name(np_pool); } - if (pdev) + if (pdev) { pool = gen_pool_get(&pdev->dev, name); + put_device(&pdev->dev); + } + of_node_put(np_pool); return pool; _ Patches currently in -mm which might be from johan(a)kernel.org are

2 months, 2 weeks

1
0
0 0

[merged mm-nonmm-stable] squashfs-fix-uninit-value-in-squashfs_get_parent.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: Squashfs: fix uninit-value in squashfs_get_parent has been removed from the -mm tree. Its filename was squashfs-fix-uninit-value-in-squashfs_get_parent.patch This patch was dropped because it was merged into the mm-nonmm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Phillip Lougher <phillip(a)squashfs.org.uk> Subject: Squashfs: fix uninit-value in squashfs_get_parent Date: Fri, 19 Sep 2025 00:33:08 +0100 Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug. This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory. Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent; Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access. The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned. Regular inodes used to share the parent field with the block_list_start field. This is removed in this commit to enable the parent field to contain the invalid inode number 0. Link: https://lkml.kernel.org/r/20250918233308.293861-1-phillip@squashfs.org.uk Fixes: 122601408d20 ("Squashfs: export operations") Signed-off-by: Phillip Lougher <phillip(a)squashfs.org.uk> Reported-by: syzbot+157bdef5cf596ad0da2c(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68cc2431.050a0220.139b6.0001.GAE@google.com/ Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/squashfs/inode.c | 7 +++++++ fs/squashfs/squashfs_fs_i.h | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) --- a/fs/squashfs/inode.c~squashfs-fix-uninit-value-in-squashfs_get_parent +++ a/fs/squashfs/inode.c @@ -169,6 +169,7 @@ int squashfs_read_inode(struct inode *in squashfs_i(inode)->start = le32_to_cpu(sqsh_ino->start_block); squashfs_i(inode)->block_list_start = block; squashfs_i(inode)->offset = offset; + squashfs_i(inode)->parent = 0; inode->i_data.a_ops = &squashfs_aops; TRACE("File inode %x:%x, start_block %llx, block_list_start " @@ -216,6 +217,7 @@ int squashfs_read_inode(struct inode *in squashfs_i(inode)->start = le64_to_cpu(sqsh_ino->start_block); squashfs_i(inode)->block_list_start = block; squashfs_i(inode)->offset = offset; + squashfs_i(inode)->parent = 0; inode->i_data.a_ops = &squashfs_aops; TRACE("File inode %x:%x, start_block %llx, block_list_start " @@ -296,6 +298,7 @@ int squashfs_read_inode(struct inode *in inode->i_mode |= S_IFLNK; squashfs_i(inode)->start = block; squashfs_i(inode)->offset = offset; + squashfs_i(inode)->parent = 0; if (type == SQUASHFS_LSYMLINK_TYPE) { __le32 xattr; @@ -333,6 +336,7 @@ int squashfs_read_inode(struct inode *in set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); rdev = le32_to_cpu(sqsh_ino->rdev); init_special_inode(inode, inode->i_mode, new_decode_dev(rdev)); + squashfs_i(inode)->parent = 0; TRACE("Device inode %x:%x, rdev %x\n", SQUASHFS_INODE_BLK(ino), offset, rdev); @@ -357,6 +361,7 @@ int squashfs_read_inode(struct inode *in set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); rdev = le32_to_cpu(sqsh_ino->rdev); init_special_inode(inode, inode->i_mode, new_decode_dev(rdev)); + squashfs_i(inode)->parent = 0; TRACE("Device inode %x:%x, rdev %x\n", SQUASHFS_INODE_BLK(ino), offset, rdev); @@ -377,6 +382,7 @@ int squashfs_read_inode(struct inode *in inode->i_mode |= S_IFSOCK; set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); init_special_inode(inode, inode->i_mode, 0); + squashfs_i(inode)->parent = 0; break; } case SQUASHFS_LFIFO_TYPE: @@ -396,6 +402,7 @@ int squashfs_read_inode(struct inode *in inode->i_op = &squashfs_inode_ops; set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); init_special_inode(inode, inode->i_mode, 0); + squashfs_i(inode)->parent = 0; break; } default: --- a/fs/squashfs/squashfs_fs_i.h~squashfs-fix-uninit-value-in-squashfs_get_parent +++ a/fs/squashfs/squashfs_fs_i.h @@ -16,6 +16,7 @@ struct squashfs_inode_info { u64 xattr; unsigned int xattr_size; int xattr_count; + int parent; union { struct { u64 fragment_block; @@ -27,7 +28,6 @@ struct squashfs_inode_info { u64 dir_idx_start; int dir_idx_offset; int dir_idx_cnt; - int parent; }; }; struct inode vfs_inode; _ Patches currently in -mm which might be from phillip(a)squashfs.org.uk are

2 months, 2 weeks

1
0
0 0

[merged mm-nonmm-stable] kho-only-fill-kimage-if-kho-is-finalized.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kho: only fill kimage if KHO is finalized has been removed from the -mm tree. Its filename was kho-only-fill-kimage-if-kho-is-finalized.patch This patch was dropped because it was merged into the mm-nonmm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Pratyush Yadav <pratyush(a)kernel.org> Subject: kho: only fill kimage if KHO is finalized Date: Thu, 18 Sep 2025 19:06:15 +0200 kho_fill_kimage() only checks for KHO being enabled before filling in the FDT to the image. KHO being enabled does not mean that the kernel has data to hand over. That happens when KHO is finalized. When a kexec is done with KHO enabled but not finalized, the FDT page is allocated but not initialized. FDT initialization happens after finalize. This means the KHO segment is filled in but the FDT contains garbage data. This leads to the below error messages in the next kernel: [ 0.000000] KHO: setup: handover FDT (0x10116b000) is invalid: -9 [ 0.000000] KHO: disabling KHO revival: -22 There is no problem in practice, and the next kernel boots and works fine. But this still leads to misleading error messages and garbage being handed over. Only fill in KHO segment when KHO is finalized. When KHO is not enabled, the debugfs interface is not created and there is no way to finalize it anyway. So the check for kho_enable is not needed, and kho_out.finalize alone is enough. Link: https://lkml.kernel.org/r/20250918170617.91413-1-pratyush@kernel.org Fixes: 3bdecc3c93f9 ("kexec: add KHO support to kexec file loads") Signed-off-by: Pratyush Yadav <pratyush(a)kernel.org> Reviewed-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Cc: Alexander Graf <graf(a)amazon.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Changyuan Lyu <changyuanl(a)google.com> Cc: Jason Gunthorpe <jgg(a)nvidia.com> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/kexec_handover.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/kexec_handover.c~kho-only-fill-kimage-if-kho-is-finalized +++ a/kernel/kexec_handover.c @@ -1253,7 +1253,7 @@ int kho_fill_kimage(struct kimage *image int err = 0; struct kexec_buf scratch; - if (!kho_enable) + if (!kho_out.finalized) return 0; image->kho.fdt = page_to_phys(kho_out.ser.fdt); _ Patches currently in -mm which might be from pratyush(a)kernel.org are kho-add-support-for-preserving-vmalloc-allocations-fix.patch

2 months, 2 weeks

1
0
0 0

Re: Watermark (917) 267-9470

by Jim Solesky

Good Sunday morning, We hope 2025 has been strong heading into Fall. We continue to look forward to opportunities in structuring funding approval to offer you this year. With hopes of inflation rates continuing to come down, combining with a growing market, Watermark's rates have been and will be as competitive as ever for: * Credit Lines - Working Capital * All Property * All Equipment * Equity Raises - Buyouts We are available to review your fundraising needs around the world on behalf of you and any clients that you may have ready for us. Thank you! Jim Solesky, Managing Partner Office: (917) 267-9470 1 Bryant Park | Bank of America Tower New York, NY, United States 10036 [image5]

2 months, 2 weeks

1
0
0 0

D rings , O rings ,clasps ,clips , Plastic hardware ,fastening,rivets , grommets,eyelets,buckles,screws , harnesses ,wires ,bolts ,nuts ,clips ,bits ,spurs ,screws,anchors,stainless

by qualityproduct＠vip.163.com

Dear Sir : I hope you’re doing well! My name is Su, and I represent METAL PRODUCTS, a leading manufacturer of premium metal hardware. We specialize in a wide range of products, including: D rings , O rings ,clasps ,clips , Plastic hardware ,fastening,rivets , grommets,eyelets,buckles,screws , harnesses ,wires ,bolts ,nuts ,clips ,bits ,spurs ,screws,anchors,stainless steel hardware , zamak harnesses,aluminium hardware，brass hardware,steel harnesses ,iron metal hardware,metal & Harnesses,belt and buckles,straps ,leather Harnesses,tags ,belts,straps ,clips ,rings bars ,hooks , safety buckles,brass buckles, brass rings ,belts,buckles ,Split Ring ,straps ,sliders,snaps ,Bars Rings, Fasteners, magnent buttons,craft hardware ,bindings ,knobs,steps ,straps , bits ,eyelets ,tools , metal gear , metal hardware , metal products, metal Components,S hooks ,bars ,snaps ,webbings , buckles, HOOK,brass buckles, clips , hooks ,straps , accessories ,steel wires, wire rings , wire buckles ,brass gears ,brass products ,iron metal hardware ,Fasteners,safety buckles,brass buckles, brass rings ,belts,buckles ,Ring ,Squares ,straps ,sliders,Bars Rings, Buckles, Cord locks, Hooks & Rings,Tabs, Locks and Slides,magnent buttons,carabiners,trigger ,buttons ,snaps ,fasteners, webbings , webbing buckles, buttons, as required for our global clients .Hook Loop ，textile accessories,safety buckles,sliders,snaps ,leather hardware ,bag hardware ,shoe hardware ,cord hardware ,hockey hardware,Rings ,chains,suspenders,custom designs and more ! We are manufactory, we are the source, our price is very competitive ,you will get the best price , We have profuse designs with series quality grade, and expressly. Our factory always produce customer designs and drawing , if you have any products looking please let me know we could surely make for you Sincerely hope could work with you ! Best regards Su

2 months, 2 weeks

1
0
0 0

[for-linus][PATCH 3/3] tracing: fgraph: Protect return handler from recursion loop

by Steven Rostedt

From: "Masami Hiramatsu (Google)" <mhiramat(a)kernel.org> function_graph_enter_regs() prevents itself from recursion by ftrace_test_recursion_trylock(), but __ftrace_return_to_handler(), which is called at the exit, does not prevent such recursion. Therefore, while it can prevent recursive calls from fgraph_ops::entryfunc(), it is not able to prevent recursive calls to fgraph from fgraph_ops::retfunc(), resulting in a recursive loop. This can lead an unexpected recursion bug reported by Menglong. is_endbr() is called in __ftrace_return_to_handler -> fprobe_return -> kprobe_multi_link_exit_handler -> is_endbr. To fix this issue, acquire ftrace_test_recursion_trylock() in the __ftrace_return_to_handler() after unwind the shadow stack to mark this section must prevent recursive call of fgraph inside user-defined fgraph_ops::retfunc(). This is essentially a fix to commit 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer"), because before that fgraph was only used from the function graph tracer. Fprobe allowed user to run any callbacks from fgraph after that commit. Reported-by: Menglong Dong <menglong8.dong(a)gmail.com> Closes: https://lore.kernel.org/all/20250918120939.1706585-1-dongml2@chinatelecom.c… Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer") Cc: stable(a)vger.kernel.org Cc: Peter Zijlstra <peterz(a)infradead.org> Link: https://lore.kernel.org/175852292275.307379.9040117316112640553.stgit@devno… Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Tested-by: Menglong Dong <menglong8.dong(a)gmail.com> Acked-by: Menglong Dong <menglong8.dong(a)gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/fgraph.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c index 1e3b32b1e82c..484ad7a18463 100644 --- a/kernel/trace/fgraph.c +++ b/kernel/trace/fgraph.c @@ -815,6 +815,7 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe unsigned long bitmap; unsigned long ret; int offset; + int bit; int i; ret_stack = ftrace_pop_return_trace(&trace, &ret, frame_pointer, &offset); @@ -829,6 +830,15 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe if (fregs) ftrace_regs_set_instruction_pointer(fregs, ret); + bit = ftrace_test_recursion_trylock(trace.func, ret); + /* + * This can fail because ftrace_test_recursion_trylock() allows one nest + * call. If we are already in a nested call, then we don't probe this and + * just return the original return address. + */ + if (unlikely(bit < 0)) + goto out; + #ifdef CONFIG_FUNCTION_GRAPH_RETVAL trace.retval = ftrace_regs_get_return_value(fregs); #endif @@ -852,6 +862,8 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe } } + ftrace_test_recursion_unlock(bit); +out: /* * The ftrace_graph_return() may still access the current * ret_stack structure, we need to make sure the update of -- 2.50.1

2 months, 2 weeks

1
0
0 0

[PATCH v2] soc: samsung: exynos-pmu: fix reference leak in exynos_get_pmu_regmap_by_phandle()

by Ma Ke

In exynos_get_pmu_regmap_by_phandle(), driver_find_device_by_of_node() utilizes driver_find_device_by_fwnode() which internally calls driver_find_device() to locate the matching device. driver_find_device() increments the reference count of the found device by calling get_device(), but exynos_get_pmu_regmap_by_phandle() fails to call put_device() to decrement the reference count before returning. This results in a reference count leak of the device each time exynos_get_pmu_regmap_by_phandle() is executed, which may prevent the device from being properly released and cause a memory leak. Since Exynos-PMU is a core system device that is not unloaded at runtime, and regmap is created during device probing, releasing the temporary device reference does not affect the validity of regmap. From the perspective of code standards and maintainability, reference count leakage is a genuine code defect that should be fixed. Even if the leakage does not immediately cause issues in certain scenarios, known leakage points should not be left unaddressed. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 0b7c6075022c ("soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v2: - modified the typo of the variable in the patch. Sorry for the typo; - added more detailed description. --- drivers/soc/samsung/exynos-pmu.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c index a77288f49d24..b80cc30c1100 100644 --- a/drivers/soc/samsung/exynos-pmu.c +++ b/drivers/soc/samsung/exynos-pmu.c @@ -302,6 +302,7 @@ struct regmap *exynos_get_pmu_regmap_by_phandle(struct device_node *np, { struct device_node *pmu_np; struct device *dev; + struct regmap *regmap; if (propname) pmu_np = of_parse_phandle(np, propname, 0); @@ -325,7 +326,10 @@ struct regmap *exynos_get_pmu_regmap_by_phandle(struct device_node *np, if (!dev) return ERR_PTR(-EPROBE_DEFER); - return syscon_node_to_regmap(pmu_np); + regmap = syscon_node_to_regmap(pmu_np); + put_device(dev); + + return regmap; } EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle); -- 2.17.1

2 months, 2 weeks

2
1
0 0

Re: [PATCH] Bluetooth: btusb: Add one more ID 0x13d3:0x3612 for Realtek 8852CE

by Paul Menzel

Dear Levi, Thank you for your reply. Am 28.09.25 um 06:41 schrieb Levi Zim: > On 9/27/25 10:25 PM, Paul Menzel wrote: >> For the summary/title “one more” is not necessary. >> > I just blindly followed the format of the last commit that touches that > file. > Should I send a V2 with “one more” removed? No need to resend from my side. >> Am 27.09.25 um 04:29 schrieb Levi Zim via B4 Relay: >>> From: Levi Zim <rsworktech(a)outlook.com> >>> >>> Devices with ID 13d3:3612 are found in ASUS TUF Gaming A16 (2025) >>> and ASUS TX Gaming FA608FM. >>> >>> The corresponding device info from /sys/kernel/debug/usb/devices is >>> >>> T: Bus=03 Lev=02 Prnt=03 Port=02 Cnt=02 Dev#= 6 Spd=12 MxCh= 0 >>> D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 >>> P: Vendor=13d3 ProdID=3612 Rev= 0.00 >>> S: Manufacturer=Realtek >>> S: Product=Bluetooth Radio >>> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA >>> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb >>> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms >>> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms >>> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms >>> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb >>> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms >>> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms >>> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb >>> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms >>> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms >>> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb >>> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms >>> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms >>> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb >>> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms >>> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms >>> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb >>> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms >>> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms >>> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb >>> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms >>> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms >>> I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb >>> E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms >>> E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms >>> >>> Signed-off-by: Levi Zim <rsworktech(a)outlook.com> >>> --- >>> drivers/bluetooth/btusb.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c >>> index >>> 8085fabadde8ff01171783b59226589757bbbbbc..d1e62b3158166a33153a6dfaade03fd3fb7d8231 100644 >>> --- a/drivers/bluetooth/btusb.c >>> +++ b/drivers/bluetooth/btusb.c >>> @@ -552,6 +552,8 @@ static const struct usb_device_id quirks_table[] = { >>> BTUSB_WIDEBAND_SPEECH }, >>> { USB_DEVICE(0x13d3, 0x3592), .driver_info = BTUSB_REALTEK | >>> BTUSB_WIDEBAND_SPEECH }, >>> + { USB_DEVICE(0x13d3, 0x3612), .driver_info = BTUSB_REALTEK | >>> + BTUSB_WIDEBAND_SPEECH }, >>> { USB_DEVICE(0x0489, 0xe122), .driver_info = BTUSB_REALTEK | >>> BTUSB_WIDEBAND_SPEECH }, >> Reviewed-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Kind regards, Paul

2 months, 2 weeks

1
0
0 0

[PATCH v2] ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free

by Jeongjun Park

The previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at removal") patched a UAF issue caused by the error timer. However, because the error timer kill added in this patch occurs after the endpoint delete, a race condition to UAF still occurs, albeit rarely. Additionally, since kill-cleanup for urb is also missing, freed memory can be accessed in interrupt context related to urb, which can cause UAF. Therefore, to prevent this, error timer and urb must be killed before freeing the heap memory. Cc: <stable(a)vger.kernel.org> Reported-by: syzbot+f02665daa2abeef4a947(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f02665daa2abeef4a947 Fixes: 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at removal") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> --- sound/usb/midi.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/sound/usb/midi.c b/sound/usb/midi.c index acb3bf92857c..97e7e7662b12 100644 --- a/sound/usb/midi.c +++ b/sound/usb/midi.c @@ -1522,15 +1522,14 @@ static void snd_usbmidi_free(struct snd_usb_midi *umidi) { int i; + if (!umidi->disconnected) + snd_usbmidi_disconnect(&umidi->list); + for (i = 0; i < MIDI_MAX_ENDPOINTS; ++i) { struct snd_usb_midi_endpoint *ep = &umidi->endpoints[i]; - if (ep->out) - snd_usbmidi_out_endpoint_delete(ep->out); - if (ep->in) - snd_usbmidi_in_endpoint_delete(ep->in); + kfree(ep->out); } mutex_destroy(&umidi->mutex); - timer_shutdown_sync(&umidi->error_timer); kfree(umidi); } --

2 months, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror