- 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 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 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 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 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 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 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 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 weeks, 1 day

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 weeks, 1 day

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 weeks, 1 day

2
1
0 0

[PATCH] iommu/amd: Fix pci_segment memleak in alloc_pci_segment()

by Jinhui Guo

Fix a memory leak of struct amd_iommu_pci_segment in alloc_pci_segment() when system memory (or contiguous memory) is insufficient. Fixes: 04230c119930 ("iommu/amd: Introduce per PCI segment device table") Fixes: eda797a27795 ("iommu/amd: Introduce per PCI segment rlookup table") Fixes: 99fc4ac3d297 ("iommu/amd: Introduce per PCI segment alias_table") Cc: stable(a)vger.kernel.org Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> --- drivers/iommu/amd/init.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index ba9e582a8bbe..77afd5884984 100644 --- a/drivers/iommu/amd/init.c +++ b/drivers/iommu/amd/init.c @@ -1608,13 +1608,22 @@ static struct amd_iommu_pci_seg *__init alloc_pci_segment(u16 id, list_add_tail(&pci_seg->list, &amd_iommu_pci_seg_list); if (alloc_dev_table(pci_seg)) - return NULL; + goto err_free_pci_seg; if (alloc_alias_table(pci_seg)) - return NULL; + goto err_free_dev_table; if (alloc_rlookup_table(pci_seg)) - return NULL; + goto err_free_alias_table; return pci_seg; + +err_free_alias_table: + free_alias_table(pci_seg); +err_free_dev_table: + free_dev_table(pci_seg); +err_free_pci_seg: + list_del(&pci_seg->list); + kfree(pci_seg); + return NULL; } static struct amd_iommu_pci_seg *__init get_pci_segment(u16 id, -- 2.20.1

2 weeks, 1 day

1
0
0 0

[PATCH] i2c: fix reference leak in MP2 PCI device

by Ma Ke

In i2c_amd_probe(), amd_mp2_find_device() utilizes driver_find_next_device() 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 amd_mp2_find_device() fails to call put_device() to decrement the reference count before returning. This results in a reference count leak of the PCI device each time i2c_amd_probe() is executed, which may prevent the device from being properly released and cause a memory leak. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 529766e0a011 ("i2c: Add drivers for the AMD PCIe MP2 I2C controller") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/i2c/busses/i2c-amd-mp2-pci.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-amd-mp2-pci.c b/drivers/i2c/busses/i2c-amd-mp2-pci.c index ef7370d3dbea..1f01d3f121ba 100644 --- a/drivers/i2c/busses/i2c-amd-mp2-pci.c +++ b/drivers/i2c/busses/i2c-amd-mp2-pci.c @@ -464,7 +464,9 @@ struct amd_mp2_dev *amd_mp2_find_device(void) return NULL; pci_dev = to_pci_dev(dev); - return (struct amd_mp2_dev *)pci_get_drvdata(pci_dev); + mp2_dev = (struct amd_mp2_dev *)pci_get_drvdata(pci_dev); + put_device(dev); + return mp2_dev; } EXPORT_SYMBOL_GPL(amd_mp2_find_device); -- 2.17.1

2 weeks, 1 day

4
4
0 0

[PATCH] 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. 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> --- 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..ed903a2dd416 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(regmap); + + return regmap; } EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle); -- 2.17.1

2 weeks, 1 day

2
2
0 0

[i2c-host PATCH i2c-host-fixes v7 0/2] i2c: rtl9300: Implement I2C block read and write

by Sven Eckelmann

This patch was already applied [1] but then removed. Instead, only the chunk @@ -314,7 +343,7 @@ static u32 rtl9300_i2c_func(struct i2c_adapter *a) { return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE | I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA | - I2C_FUNC_SMBUS_BLOCK_DATA; + I2C_FUNC_SMBUS_BLOCK_DATA | I2C_FUNC_SMBUS_I2C_BLOCK; } was added as part of a patch which has nothing to do with I2C_FUNC_SMBUS_I2C_BLOCK [2] and was never submitted like this [3]. I am therefore resubmitting this patch again with a patch that is removing the errornous I2C_FUNC_SMBUS_I2C_BLOCK from i2c-host-fixes. Order: * The first patch needs to be applied on top of i2c-host-fixes * after i2c-host-fixes (with this patch) is included in the i2c-host branch: - the second patch from this series - The patches 4-12 from Jonas [4] need to be applied on top of it in the i2c-host branch: + https://lore.kernel.org/r/20250831100457.3114-5-jelonek.jonas@gmail.com + https://lore.kernel.org/r/20250831100457.3114-6-jelonek.jonas@gmail.com + https://lore.kernel.org/r/20250831100457.3114-7-jelonek.jonas@gmail.com + https://lore.kernel.org/r/20250831100457.3114-8-jelonek.jonas@gmail.com + https://lore.kernel.org/r/20250831100457.3114-9-jelonek.jonas@gmail.com + https://lore.kernel.org/r/20250831100457.3114-10-jelonek.jonas@gmail.com + https://lore.kernel.org/r/20250831100457.3114-11-jelonek.jonas@gmail.com + https://lore.kernel.org/r/20250831100457.3114-12-jelonek.jonas@gmail.com + https://lore.kernel.org/r/20250831100457.3114-13-jelonek.jonas@gmail.com [1] https://lore.kernel.org/r/a422shurtl3xrvnh2ieynqq2kw5awqnmall2wjdpozx336m26… [2] https://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git/commit… [3] https://lore.kernel.org/r/20250831100457.3114-4-jelonek.jonas@gmail.com [4] https://lore.kernel.org/r/20250831100457.3114-1-jelonek.jonas@gmail.com Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- Changes in v7: - Split into two patches. One for i2c-host-fixes to remove the actually unsupported I2C_FUNC_SMBUS_I2C_BLOCK. The next one is for i2c-host and readds it with the correct code. - Link to v6: https://lore.kernel.org/r/20250926-i2c-rtl9300-multi-byte-v6-1-a2d7d8926105… Changes in v6: - drop all fixes patches (which were already applied) - drop rtl9300_i2c_func chunk which was incorrectly added by another commit [2] (but was not intended to be in there by the original patch [3] - Link to v5: https://lore.kernel.org/r/20250810-i2c-rtl9300-multi-byte-v5-0-cd9dca0db722… Changes in v5: - Simplify function/capability registration by using I2C_FUNC_SMBUS_I2C_BLOCK, thanks Jonas Jelonek - Link to v4: https://lore.kernel.org/r/20250809-i2c-rtl9300-multi-byte-v4-0-d71dd5eb6121… Changes in v4: - Provide only "write" examples for "i2c: rtl9300: Fix multi-byte I2C write" - drop the second initialization of vals in rtl9300_i2c_write() directly in the "Fix multi-byte I2C write" fix - indicate in target branch for each patch in PATCH prefix - minor commit message cleanups - Link to v3: https://lore.kernel.org/r/20250804-i2c-rtl9300-multi-byte-v3-0-e20607e1b28c… Changes in v3: - integrated patch https://lore.kernel.org/r/20250615235248.529019-1-alexguo1023@gmail.com to avoid conflicts in the I2C_SMBUS_BLOCK_DATA code - added Fixes and stable(a)vger.kernel.org to Alex Guo's patch - added Chris Packham's Reviewed-by/Acked-by - Link to v2: https://lore.kernel.org/r/20250803-i2c-rtl9300-multi-byte-v2-0-9b7b759fe2b6… Changes in v2: - add the missing transfer width and read length increase for the SMBus Write/Read - Link to v1: https://lore.kernel.org/r/20250802-i2c-rtl9300-multi-byte-v1-0-5f687e0098e2… --- Harshal Gohel (1): [i2c-host] i2c: rtl9300: Implement I2C block read and write Sven Eckelmann (1): [i2c-host-fixes] i2c: rtl9300: Drop unsupported I2C_FUNC_SMBUS_BLOCK_DATA drivers/i2c/busses/i2c-rtl9300.c | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) --- base-commit: 217f92d91c9faeb6b78bd6205b3585944cbcb433 change-id: 20250802-i2c-rtl9300-multi-byte-edaa1fb0872c Best regards, -- Sven Eckelmann <sven(a)narfation.org>

2 weeks, 1 day

2
2
0 0

Gratulujeme, ponuka daru

by Kristine Charity Services

2 weeks, 1 day

1
0
0 0

[PATCH] drm/tegra: dc: fix reference leak in tegra_dc_couple()

by Ma Ke

driver_find_device() calls get_device() to increment the reference count once a matching device is found, but there is no put_device() to balance the reference count. To avoid reference count leakage, add put_device() to decrease the reference count. Found by code review. Cc: stable(a)vger.kernel.org Fixes: a31500fe7055 ("drm/tegra: dc: Restore coupling of display controllers") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/gpu/drm/tegra/dc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 59d5c1ba145a..6c84bd69b11f 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -3148,6 +3148,7 @@ static int tegra_dc_couple(struct tegra_dc *dc) dc->client.parent = &parent->client; dev_dbg(dc->dev, "coupled to %s\n", dev_name(companion)); + put_device(companion); } return 0; -- 2.17.1

2 weeks, 1 day

3
2
0 0

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

by 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 }, --- base-commit: 302a1f674c00dd5581ab8e493ef44767c5101aab change-id: 20250927-ble-13d3-3612-53a2246e4862 Best regards, -- Levi Zim <rsworktech(a)outlook.com>

2 weeks, 1 day

3
2
0 0

[PATCH] 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. Therefore, to prevent this, the error timer must be killed before freeing the heap memory. Cc: <stable(a)vger.kernel.org> Fixes: 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at removal") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> --- sound/usb/midi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/usb/midi.c b/sound/usb/midi.c index acb3bf92857c..8d15f1caa92b 100644 --- a/sound/usb/midi.c +++ b/sound/usb/midi.c @@ -1522,6 +1522,8 @@ static void snd_usbmidi_free(struct snd_usb_midi *umidi) { int i; + timer_shutdown_sync(&umidi->error_timer); + for (i = 0; i < MIDI_MAX_ENDPOINTS; ++i) { struct snd_usb_midi_endpoint *ep = &umidi->endpoints[i]; if (ep->out) @@ -1530,7 +1532,6 @@ static void snd_usbmidi_free(struct snd_usb_midi *umidi) snd_usbmidi_in_endpoint_delete(ep->in); } mutex_destroy(&umidi->mutex); - timer_shutdown_sync(&umidi->error_timer); kfree(umidi); } --

2 weeks, 1 day

2
3
0 0

Website Designing, Mobile Apps & Tie-ups.

by Sales Bard India

Greetings!! We are a 24+ yr old high tech Web Development firm with presence of over 18+ yrs in Mauritius; partners of RV TechAdvisora Ltd and headquartered in India We have catered to over 7000 trendy websites; are a team of 30 people. Our Services: Domain Registrations, Webhosting, Google Workspace, Mobile Responsive Website Designing, Wordpress Websites, Mobile Apps, Web Apps, E-commerce websites, Google Ads, SEO, Catalogue design & affiliated services Find below some of the ready packages we offer for making an easy selection for the kind of Mobile Responsive HTML Website: 5 page Responsive Website @ MUR 13,499/- 10 page Responsive Website @ MUR 19,999/- 15 page Responsive Website @ MUR 25,499/- 20 page Responsive Website @ MUR 31,499/- 25 page Responsive Website @ MUR 36,499/- 30 page Responsive Website @ MUR 40,999/- Additional page beyond 30 pages @ MUR 1199 per page Find below some of the ready packages we offer for making an easy selection for the kind of Mobile Responsive Wordpress Website; With Wordpress CMS, website content can be easily maintained by your company with a backend login. 5 page Responsive Website @ MUR 14,999/- 10 page Responsive Website @ MUR 21,999/- 15 page Responsive Website @ MUR 27,499/- 20 page Responsive Website @ MUR 32,999/- 25 page Responsive Website @ MUR 36,999/- 30 page Responsive Website @ MUR 40,999/- Additional page beyond 30 pages @ MUR 1199 per page Our brief website portfolio: http://www.mirackle.com/portfolio.html Note: We are also looking for tie-ups with IT/Web design cos. who would want to outsource work for high end Websites/Mobile APP requirements etc. We have a team of highly skilled php coders who can cater to any complex requirement. India Whatsapp: +91 9323272846 / 9323551195; Mauritius WharsApp: +230 5758 5497; Email: business(a)mirackle.com ; Web: http://www.mirackle.com Regards, Amit Patel

2 weeks, 2 days

1
0
0 0

[PATCH] perf: arm_cspmu: fix error handling in arm_cspmu_impl_unregister()

by Ma Ke

driver_find_device() calls get_device() to increment the reference count once a matching device is found. device_release_driver() releases the driver, but it does not decrease the reference count that was incremented by driver_find_device(). At the end of the loop, there is no put_device() to balance the reference count. To avoid reference count leakage, add put_device() to decrease the reference count. Found by code review. Cc: stable(a)vger.kernel.org Fixes: bfc653aa89cb ("perf: arm_cspmu: Separate Arm and vendor module") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/perf/arm_cspmu/arm_cspmu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c index efa9b229e701..e0d4293f06f9 100644 --- a/drivers/perf/arm_cspmu/arm_cspmu.c +++ b/drivers/perf/arm_cspmu/arm_cspmu.c @@ -1365,8 +1365,10 @@ void arm_cspmu_impl_unregister(const struct arm_cspmu_impl_match *impl_match) /* Unbind the driver from all matching backend devices. */ while ((dev = driver_find_device(&arm_cspmu_driver.driver, NULL, - match, arm_cspmu_match_device))) + match, arm_cspmu_match_device))) { device_release_driver(dev); + put_device(dev); + } mutex_lock(&arm_cspmu_lock); -- 2.17.1

2 weeks, 2 days

2
1
0 0

Qualcomm Inventory Updated

by Alan Ye

The following are all Qualcomm's stock, original and authentic. If you need them, please contact us. Snapdragon骁龙 WIFI-5G/6G MPN QTY date code MPN QTY date code SM-6225-0-PSP807-TR-00-0-AB 8000 22+ IPQ5018-0-MRQFN232-MT-01-0 36000 22+ PM-6225-0-FOWNSP144-TR-01-0 8000 22+ QCN6102-0-DRQFN116-TR-01-0 30000 22+ WCD9375-0-WLPSP55-TR-01-3 8000 22+ QCA8337-AL3C 25000 22+ WTR3925-2-106BWLPSP-TR-03-1 8000 22+ WCN-3950-0-58WLPSP-TR-05-2 8000 22+ IPQ-6000-0-FCBGA570-TR-00-0 10000 22+ QCA-8072-0-108DRQFN-MT-00-0 10000 22+ QCM-6490-1-PSP1287-TR-00-0-AA E 12000 23+ QCN-5022-0-DRQFN100B-TR-00-0 10000 22+ PMK-7325-1-1-FOWPSP36-MT-01-0 12000 23+ QCN-5052-0-DRQFN100B-TR-00-0 10000 22+ PM-7325-0-WLNSP120B-TR-00-0 12000 23+ PM-7350C-0-FOWNSP143-MT-02-0 12000 23+ IPQ-6010-0-FCBGA570-TR-00-0 8000 22+ PM-7250B-2-FOWPSP110-TR-00-0 12000 23+ QCA-8075-0-108DRQFN-MT-01-0 8000 22+ WCD-9370-0-WLPSP55-TR-01-0 12000 23+ QCN-5052-0-DRQFN100B-TR-00-0 8000 22+ PM-8008-0-WLPSP20-TR-X0-0 12000 23+ QCN-5021-0-DRQFN100B-TR-03-0 8000 22+ SDR-735-0-PSP219B-TR-001-0 12000 23+ WCN-6750-0-PSP229-TR-01-0 12000 23+ QCA-9886-0-100DRQFN-MT-04-0 14000 22+ QCA9563-AL3A 14000 22+ SDM-450-B-792NSP-TR-01-0-AA 20000 24+ QCA8334-AL3C 14000 22+ WTR-2965-0-59F0WNSP-TR-07-1 20000 24+ PMI-8952-0-144WLNSP-TR-02-0-00 20000 24+ IPQ-5322-0-MRQFN251-MT-00-0 6000 24+ WCN-3680B-0-79BWLNSP-TR-05-1 20000 24+ QCN-6274-0-MSP264-MT-01-0 6000 24+ PM-8953-0-187F0WNSP-TR-01-1 20000 24+ QCA-8385-0-DRQFN172-MT-00-0 6000 24 SDM-660-3-692NSP-TR-01-0-A 28000 23+ IPQ-4018-0-180DRQFN-MT-00-0 150000 22+ PM-660-0-219WLPSP-TR-01-1-01 28000 23+ QCA-8072-0-108DRQFN-MT-00-0 100000 22+ PM-660L-0-196WLPSP-TR-04-0-01 28000 23+ SDR-660-0-180WLPSP-TR-03-0 28000 23+ QCN-9024-0-MSP234-TR-01-0 5000 23+ QET-4101-0-12WLNSP-HR-00-0 28000 23+ QCN-6024-0-MSP234-MT-01-0 20000 22+ WCN-3980-0-82BWLPSP-TR-0B-0 28000 23+ QCA-8081-0-56MQFN-MT-02-0 28000 22+ QCN-9074-0-MSP234-TR-01-0 8000 23+ QCM-2290-0-NSP752-TR-00-0 10000 24+ QCA-9377-3-115WLNSP-TR-03-0 10000 22+ PM-8008-0-WLPSP20-TR-X0-0 10000 24+ QCA-1023-0-115WLNSP-TR-03-0 20000 24+ WCN-3950-0-58WLPSP-TR-05-3 10000 24+ QCC-5181-0-WLNSP99-TR-05-0 10000 24+ PM-4125-3-NSP194-TR-01-0 10000 24+ QCC-5127-0-124CSP-TR-00-0 8000 23+ CSR8670C-ICXT-R 10000 23+ MSM-8909-2-504NSP-TR-01-1-AA 50000 22+ CSR8675C-IBBH-R 10000 23+ WCN-3660B-0-79BWLNSP-TR-05-1 50000 22+ AR8033-AL1A 25000 23+ PM-8909-0-152NSP-TR-01-0-02 50000 22+ AR8035-AL1A 45000 22+ WTR-4905-1-60WLNSP-TR-01-1 50000 22+ AR8031-AL1B 15000 22+ If you have other MPN requirements, please let me know and I will check the latest inventory status for you. We also recycle Qualcomm's excess inventory to help you solve the depreciation risk faced by electronic components Best Secure your updates and feature insights at . Continue Product News Wish to step back? Quickly hit Control Contact Settings.

2 weeks, 2 days

1
0
0 0

[PATCH net-next 00/15] mptcp: pm: special case for c-flag + luminar endp

by Matthieu Baerts (NGI0)

Here are some patches for the MPTCP PM, including some refactoring that I thought it would be best to send at the end of a cycle to avoid conflicts between net and net-next that could last a few weeks. The most interesting changes are in the first and last patch, the rest are patches refactoring the code & tests to validate the modifications. - Patches 1 & 2: When servers set the C-flag in their MP_CAPABLE to tell clients not to create subflows to the initial address and port -- e.g. a deployment behind a L4 load balancer like a typical CDN deployment -- clients will not use their other endpoints when default settings are used. That's because the in-kernel path-manager uses the 'subflow' endpoints to create subflows only to the initial address and port. The first patch fixes that (for >=v5.14), and the second one validates it. - Patches 3-14: various patches refactoring the code around the in-kernel PM (mainly): split too long functions, rename variables and functions to avoid confusions, reduce structure size, and compare IDs instead of IP addresses. Note that one patch modifies one internal variable used in one BPF selftest. - Patch 15: ability to control endpoints that are used in reaction to a new address announced by the other peer. With that, endpoints can be used only once. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Notes: - Patches 1 & 2 are sent to net-next on purpose: to delay a bit the backports, just in case. Plus we are at the end of a cycle, and not to delay the other refactoring patches. - Sorry, I wanted to send this series earlier on, but due to some unrelated issues (and holiday), it got delayed. Most patches are pure refactoring ones. --- Matthieu Baerts (NGI0) (15): mptcp: pm: in-kernel: usable client side with C-flag selftests: mptcp: join: validate C-flag + def limit mptcp: pm: in-kernel: refactor fill_local_addresses_vec mptcp: pm: in-kernel: refactor fill_remote_addresses_vec mptcp: pm: rename 'subflows' to 'extra_subflows' mptcp: pm: in-kernel: rename 'subflows_max' to 'limit_extra_subflows' mptcp: pm: in-kernel: rename 'add_addr_signal_max' to 'endp_signal_max' mptcp: pm: in-kernel: rename 'add_addr_accept_max' to 'limit_add_addr_accepted' mptcp: pm: in-kernel: rename 'local_addr_max' to 'endp_subflow_max' mptcp: pm: in-kernel: rename 'local_addr_list' to 'endp_list' mptcp: pm: in-kernel: rename 'addrs' to 'endpoints' mptcp: pm: in-kernel: remove stale_loss_cnt mptcp: pm: in-kernel: reduce pernet struct size mptcp: pm: in-kernel: compare IDs instead of addresses mptcp: pm: in-kernel: add laminar endpoints include/uapi/linux/mptcp.h | 11 +- net/mptcp/pm.c | 32 +- net/mptcp/pm_kernel.c | 569 ++++++++++++++-------- net/mptcp/pm_userspace.c | 2 +- net/mptcp/protocol.h | 21 +- net/mptcp/sockopt.c | 22 +- tools/testing/selftests/bpf/progs/mptcp_subflow.c | 2 +- tools/testing/selftests/net/mptcp/mptcp_join.sh | 11 + 8 files changed, 441 insertions(+), 229 deletions(-) --- base-commit: a1f1f2422e098485b09e55a492de05cf97f9954d change-id: 20250925-net-next-mptcp-c-flag-laminar-f8442e4d4bd9 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

2 weeks, 2 days

2
3
0 0

+ squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: Squashfs: reject negative file sizes in squashfs_read_inode() has been added to the -mm mm-nonmm-unstable branch. Its filename is squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ 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. 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 | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) --- a/fs/squashfs/inode.c~squashfs-reject-negative-file-sizes-in-squashfs_read_inode +++ a/fs/squashfs/inode.c @@ -145,6 +145,10 @@ int squashfs_read_inode(struct inode *in goto failed_read; inode->i_size = le32_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) { /* @@ -197,6 +201,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) { /* @@ -249,8 +257,12 @@ int squashfs_read_inode(struct inode *in if (err < 0) goto failed_read; - set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); inode->i_size = le16_to_cpu(sqsh_ino->file_size); + if (inode->i_size < 0) { + err = -EINVAL; + goto failed_read; + } + set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); inode->i_op = &squashfs_dir_inode_ops; inode->i_fop = &squashfs_dir_ops; inode->i_mode |= S_IFDIR; @@ -273,9 +285,13 @@ int squashfs_read_inode(struct inode *in if (err < 0) goto failed_read; + inode->i_size = le32_to_cpu(sqsh_ino->file_size); + if (inode->i_size < 0) { + err = -EINVAL; + goto failed_read; + } xattr_id = le32_to_cpu(sqsh_ino->xattr); set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); - inode->i_size = le32_to_cpu(sqsh_ino->file_size); inode->i_op = &squashfs_dir_inode_ops; inode->i_fop = &squashfs_dir_ops; inode->i_mode |= S_IFDIR; @@ -302,7 +318,7 @@ int squashfs_read_inode(struct inode *in goto failed_read; inode->i_size = le32_to_cpu(sqsh_ino->symlink_size); - if (inode->i_size > PAGE_SIZE) { + if (inode->i_size < 0 || inode->i_size > PAGE_SIZE) { ERROR("Corrupted symlink\n"); return -EINVAL; } _ Patches currently in -mm which might be from phillip(a)squashfs.org.uk are squashfs-fix-uninit-value-in-squashfs_get_parent.patch squashfs-add-additional-inode-sanity-checking.patch squashfs-add-seek_data-seek_hole-support.patch squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch

2 weeks, 2 days

1
0
0 0

[PATCH] drm: mipi-dsi: Fix an API misuse in mipi_dsi_device_register_full()

by Haoxiang Li

mipi_dsi_device_alloc() calls device_initialize() to initialize value "&dsi->dev". Thus "dsi" should be freed using put_device() in error handling path. Fixes: 068a00233969 ("drm: Add MIPI DSI bus support") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- drivers/gpu/drm/drm_mipi_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c index 3a9b3278a6e3..21d9aa29ac34 100644 --- a/drivers/gpu/drm/drm_mipi_dsi.c +++ b/drivers/gpu/drm/drm_mipi_dsi.c @@ -233,7 +233,7 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host, ret = mipi_dsi_device_add(dsi); if (ret) { dev_err(host->dev, "failed to add DSI device %d\n", ret); - kfree(dsi); + put_device(&dsi->dev); return ERR_PTR(ret); } -- 2.25.1

2 weeks, 2 days

2
1
0 0

[PATCH v2 0/3] ext4: Add support for mounted updates to the superblock via an ioctl

by Theodore Ts'o via B4 Relay

This patch series enables a future version of tune2fs to be able to modify certain parts of the ext4 superblock without to write to the block device. The first patch fixes a potential buffer overrun caused by a maliciously moified superblock. The second patch adds support for 32-bit uid and gid's which can have access to the reserved blocks pool. The last patch adds the ioctl's which will be used by tune2fs. Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> --- Changes in v2: - fix bugs that were detected using sparse - remove tune (unsafe) ability to clear certain compat faatures - add the ability to set the encoding and encoding flags for case folding - Link to v1: https://lore.kernel.org/r/20250908-tune2fs-v1-0-e3a6929f3355@mit.edu --- Theodore Ts'o (3): ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() ext4: add support for 32-bit default reserved uid and gid values ext4: implemet new ioctls to set and get superblock parameters fs/ext4/ext4.h | 16 +++- fs/ext4/ioctl.c | 312 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- fs/ext4/super.c | 25 +++---- include/uapi/linux/ext4.h | 53 +++++++++++++ 4 files changed, 382 insertions(+), 24 deletions(-) --- base-commit: b320789d6883cc00ac78ce83bccbfe7ed58afcf0 change-id: 20250830-tune2fs-3376beb72403 Best regards, -- Theodore Ts'o <tytso(a)mit.edu>

2 weeks, 2 days

4
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror