- Sep 28, 2022
-
-
David Leadbeater authored
[ Upstream commit e8d5dfd1 ] CTCP messages should only be at the start of an IRC message, not anywhere within it. While the helper only decodes packes in the ORIGINAL direction, its possible to make a client send a CTCP message back by empedding one into a PING request. As-is, thats enough to make the helper believe that it saw a CTCP message. Fixes: 869f37d8 ("[NETFILTER]: nf_conntrack/nf_nat: add IRC helper port") Signed-off-by:
David Leadbeater <dgl@dgl.cx> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Igor Ryzhov authored
[ Upstream commit 39aebede ] ct_sip_next_header and ct_sip_get_header return an absolute value of matchoff, not a shift from current dataoff. So dataoff should be assigned matchoff, not incremented by it. This issue can be seen in the scenario when there are multiple Contact headers and the first one is using a hostname and other headers use IP addresses. In this case, ct_sip_walk_headers will work as follows: The first ct_sip_get_header call to will find the first Contact header but will return -1 as the header uses a hostname. But matchoff will be changed to the offset of this header. After that, dataoff should be set to matchoff, so that the next ct_sip_get_header call find the next Contact header. But instead of assigning dataoff to matchoff, it is incremented by it, which is not correct, as matchoff is an absolute value of the offset. So on the next call to the ct_sip_get_header, dataoff will be incorrect, and the next Contact header may not be found at all. Fixes: 05e3ced2 ("[NETFILTER]: nf_conntrack_sip: introduce SIP-URI parsing helper") Signed-off-by:
Igor Ryzhov <iryzhov@nfware.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Fabio Estevam authored
[ Upstream commit a994b34b ] The 'enable-active-low' property is not a valid one. Only 'enable-active-high' is valid, and when this property is absent the gpio regulator will act as active low by default. Remove the invalid 'enable-active-low' property. Fixes: 2c66fc34 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by:
Fabio Estevam <festevam@denx.de> Link: https://lore.kernel.org/r/20220827175140.1696699-1-festevam@denx.de Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chao Yu authored
commit 7e9c323c upstream. In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to out-of-memory, if it fails, return errno correctly rather than triggering panic via BUG_ON(); kernel BUG at mm/slub.c:5893! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 legacy_get_tree+0x30/0x74 fs/fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 Cc: <stable@kernel.org> Fixes: 81819f0f ("SLUB core") Reported-by:
<syzbot+81684812ea68216e08c5@syzkaller.appspotmail.com> Reviewed-by:
Muchun Song <songmuchun@bytedance.com> Reviewed-by:
Hyeonggon Yoo <42.hyeyoo@gmail.com> Signed-off-by:
Chao Yu <chao.yu@oppo.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kai Vehmanen authored
commit 4d40ceef upstream. Handle 0x3b57 variant with same AZX_DCAPS_INTEL_PCH_NOPM capabilities as 0x3b56. In practise this allow use of HDMI/DP display audio via i915. BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/2751 Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220912183716.2126312-1-kai.vehmanen@linux.intel.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mohan Kumar authored
commit 3c4d8c24 upstream. Reduce the suspend time by setting depop delay to 10ms for tegra. Signed-off-by:
Mohan Kumar <mkumard@nvidia.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220913053641.23299-1-mkumard@nvidia.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
jerry meng authored
commit d640c4cb upstream. add support for Quectel RM520N which is based on Qualcomm SDX62 chip. 0x0801: DIAG + NMEA + AT + MODEM + RMNET T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0801 Rev= 5.04 S: Manufacturer=Quectel S: Product=RM520N-GL S: SerialNumber=384af524 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by:
jerry meng <jerry-meng@foxmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Carl Yin(殷张成) authored
commit f8f67eff upstream. Add support for the following Quectel BG95 composition: 0x0203: Diag + GNSS + Modem + ECM usb-devices output: T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0203 Rev= 0.00 S: Manufacturer=Quectel, Incorporated S: Product=Quectel LPWA Module S: SerialNumber=71d3a21b C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 3 IfCount= 2 Cls=02(comm.) Sub=00 Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms I: If#= 4 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by:
Carl Yin <carl.yin@quectel.com> Cc: stable@vger.kernel.org Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
commit 766a96dc upstream. A recent commit added an invalid RST expression to a kerneldoc comment in hub.c. The fix is trivial. Fixes: 9c6d7788 ("USB: core: Prevent nested device-reset calls") Cc: <stable@vger.kernel.org> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by:
Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/YxDDcsLtRZ7c20pq@rowland.harvard.edu Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Siddh Raman Pant authored
[ Upstream commit 60deb9f1 ] ieee80211_scan_rx() tries to access scan_req->flags after a null check, but a UAF is observed when the scan is completed and __ieee80211_scan_completed() executes, which then calls cfg80211_scan_done() leading to the freeing of scan_req. Since scan_req is rcu_dereference()'d, prevent the racing in __ieee80211_scan_completed() by ensuring that from mac80211's POV it is no longer accessed from an RCU read critical section before we call cfg80211_scan_done(). Cc: stable@vger.kernel.org Link: https://syzkaller.appspot.com/bug?extid=f9acff9bf08a845f225d Reported-by:
<syzbot+f9acff9bf08a845f225d@syzkaller.appspotmail.com> Suggested-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Siddh Raman Pant <code@siddh.me> Link: https://lore.kernel.org/r/20220819200340.34826-1-code@siddh.me Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
commit 51bdc8bb upstream. The newly added stac_check_power_status() caused a compile warning when CONFIG_SND_HDA_INPUT_BEEP is disabled. Fix it. Fixes: 414d38ba ("ALSA: hda/sigmatel: Keep power up while beep is enabled") Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20220905130630.2845-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hyunwoo Kim authored
[ Upstream commit a09d2d00 ] In pxa3xx_gcu_write, a count parameter of type size_t is passed to words of type int. Then, copy_from_user() may cause a heap overflow because it is used as the third argument of copy_from_user(). Signed-off-by:
Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Youling Tang authored
[ Upstream commit c17a2538 ] When System.map was generated, the kernel used mksysmap to filter the kernel symbols, we need to filter "L0" symbols in LoongArch architecture. $ cat System.map | grep L0 9000000000221540 t L0 The L0 symbol exists in System.map, but not in .tmp_System.map. When "cmp -s System.map .tmp_System.map" will show "Inconsistent kallsyms data" error message in link-vmlinux.sh script. Signed-off-by:
Youling Tang <tangyouling@loongson.cn> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Alexander Sverdlin authored
[ Upstream commit ba912afb ] For irq_domain_associate() to work the virq descriptor has to be pre-allocated in advance. Otherwise the following happens: WARNING: CPU: 0 PID: 0 at .../kernel/irq/irqdomain.c:527 irq_domain_associate+0x298/0x2e8 error: virq128 is not allocated Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.78-... #1 ... Call Trace: [<ffffffff801344c4>] show_stack+0x9c/0x130 [<ffffffff80769550>] dump_stack+0x90/0xd0 [<ffffffff801576d0>] __warn+0x118/0x130 [<ffffffff80157734>] warn_slowpath_fmt+0x4c/0x70 [<ffffffff801b83c0>] irq_domain_associate+0x298/0x2e8 [<ffffffff80a43bb8>] octeon_irq_init_ciu+0x4c8/0x53c [<ffffffff80a76cbc>] of_irq_init+0x1e0/0x388 [<ffffffff80a452cc>] init_IRQ+0x4c/0xf4 [<ffffffff80a3cc00>] start_kernel+0x404/0x698 Use irq_alloc_desc_at() to avoid the above problem. Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
jerry.meng authored
[ Upstream commit e1091e22 ] add support for Quectel RM520N which is based on Qualcomm SDX62 chip. 0x0801: DIAG + NMEA + AT + MODEM + RMNET T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0801 Rev= 5.04 S: Manufacturer=Quectel S: Product=RM520N-GL S: SerialNumber=384af524 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by:
jerry.meng <jerry-meng@foxmail.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/tencent_E50CA8A206904897C2D20DDAE90731183C05@qq.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
[ Upstream commit 414d38ba ] It seems that the beep playback doesn't work well on IDT codec devices when the codec auto-pm is enabled. Keep the power on while the beep switch is enabled. Link: https://bugzilla.suse.com/show_bug.cgi?id=1200544 Link: https://lore.kernel.org/r/20220904072750.26164-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Xiaolei Wang authored
[ Upstream commit 78e1e867 ] The pfuze_chip::regulator_descs is an array of size PFUZE100_MAX_REGULATOR, the pfuze_chip::pfuze_regulators is the pointer to the real regulators of a specific device. The number of real regulator is supposed to be less than the PFUZE100_MAX_REGULATOR, so we should use the size of 'regulator_num * sizeof(struct pfuze_regulator)' in memcpy(). This fixes the out of bounds access bug reported by KASAN. Signed-off-by:
Xiaolei Wang <xiaolei.wang@windriver.com> Link: https://lore.kernel.org/r/20220825111922.1368055-1-xiaolei.wang@windriver.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
[ Upstream commit 5628560e ] The semaphore of nau8824 wasn't properly unlocked at some error handling code paths, hence this may result in the unbalance (and potential lock-up). Fix them to handle the semaphore up properly. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20220823081000.2965-3-tiwai@suse.de Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Stefan Metzmacher authored
commit 17d3df38 upstream. This is ignored anyway by the tcp layer. Signed-off-by:
Stefan Metzmacher <metze@samba.org> Cc: stable@vger.kernel.org Reviewed-by:
Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by:
Paulo Alcantara (SUSE) <pc@cjr.nz> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yang Yingliang authored
[ Upstream commit 38238be4 ] Add missing iounmap() before return from ccio_probe(), if ccio_init_resources() fails. Fixes: d46c742f ("parisc: ccio-dma: Handle kmalloc failure in ccio_init_resources()") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Stuart Menefy authored
[ Upstream commit 6836829c ] VIU_OSD1_CTRL_STAT.GLOBAL_ALPHA is a 9 bit field, so the maximum value is 0x100 not 0xff. This matches the vendor kernel. Signed-off-by:
Stuart Menefy <stuart.menefy@mathembedded.com> Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller") Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908155103.686904-1-stuart.menefy@mathembedded.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Pali Rohár authored
[ Upstream commit 279c12df ] Commit e39d5ef6 ("powerpc/5xxx: extend mpc8xxx_gpio driver to support mpc512x gpios") implemented support for IRQ_TYPE_LEVEL_LOW flow type in mpc512x via falling edge type. Do same for mpc85xx which support was added in commit 345e5c8a ("powerpc: Add interrupt support to mpc8xxx_gpio"). Fixes probing of lm90 hwmon driver on mpc85xx based board which use level interrupt. Without it kernel prints error and refuse lm90 to work: [ 15.258370] genirq: Setting trigger mode 8 for irq 49 failed (mpc8xxx_irq_set_type+0x0/0xf8) [ 15.267168] lm90 0-004c: cannot request IRQ 49 [ 15.272708] lm90: probe of 0-004c failed with error -22 Fixes: 345e5c8a ("powerpc: Add interrupt support to mpc8xxx_gpio") Signed-off-by:
Pali Rohár <pali@kernel.org> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Sergey Shtylyov authored
[ Upstream commit 2f945a79 ] Commit 78c44d91 ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflatten_dt_nodes() which makes it possible to overflow the nps[] buffer... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 78c44d91 ("drivers/of: Fix depth when unflattening devicetree") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/7c354554-006f-6b31-c195-cdfe4caee392@omp.ru Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
- Sep 20, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220916100441.528608977@linuxfoundation.org Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Brian Norris authored
commit 47311db8 upstream. Users may have explicitly configured their tracefs permissions; we shouldn't overwrite those just because a second mount appeared. Only clobber if the options were provided at mount time. Note: the previous behavior was especially surprising in the presence of automounted /sys/kernel/debug/tracing/. Existing behavior: ## Pre-existing status: tracefs is 0755. # stat -c '%A' /sys/kernel/tracing/ drwxr-xr-x ## (Re)trigger the automount. # umount /sys/kernel/debug/tracing # stat -c '%A' /sys/kernel/debug/tracing/. drwx------ ## Unexpected: the automount changed mode for other mount instances. # stat -c '%A' /sys/kernel/tracing/ drwx------ New behavior (after this change): ## Pre-existing status: tracefs is 0755. # stat -c '%A' /sys/kernel/tracing/ drwxr-xr-x ## (Re)trigger the automount. # umount /sys/kernel/debug/tracing # stat -c '%A' /sys/kernel/debug/tracing/. drwxr-xr-x ## Expected: the automount does not change other mount instances. # stat -c '%A' /sys/kernel/tracing/ drwxr-xr-x Link: https://lkml.kernel.org/r/20220826174353.2.Iab6e5ea57963d6deca5311b27fb7226790d44406@changeid Cc: stable@vger.kernel.org Fixes: 4282d606 ("tracefs: Add new tracefs file system") Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
[ Upstream commit c3b82d26 ] 2 keymap fixes for the Acer Aspire One AOD270 and the same hardware rebranded as Packard Bell Dot SC: 1. The F2 key is marked with a big '?' symbol on the Packard Bell Dot SC, this sends WMID_HOTKEY_EVENTs with a scancode of 0x27 add a mapping for this. 2. Scancode 0x61 is KEY_SWITCHVIDEOMODE. Usually this is a duplicate input event with the "Video Bus" input device events. But on these devices the "Video Bus" does not send events for this key. Map 0x61 to KEY_UNKNOWN instead of using KE_IGNORE so that udev/hwdb can override it on these devs. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220829163544.5288-1-hdegoede@redhat.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Li Qiong authored
[ Upstream commit ffd7bddd ] The rc code is 0 at the error path "status & CC2520_STATUS_TX_UNDERFLOW". Assign rc code with '-EINVAL' at this error path to fix it. Signed-off-by:
Li Qiong <liqiong@nfschina.com> Link: https://lore.kernel.org/r/20220829071259.18330-1-liqiong@nfschina.com Signed-off-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Kai-Heng Feng authored
[ Upstream commit 2ca1c94c ] Commit d60cd063 ("PM: ACPI: reboot: Use S5 for reboot") caused a reboot hang on one Dell servers so the commit was reverted. Someone managed to collect the AER log and it's caused by MSI: [ 148.762067] ACPI: Preparing to enter system sleep state S5 [ 148.794638] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5 [ 148.803731] {1}[Hardware Error]: event severity: recoverable [ 148.810191] {1}[Hardware Error]: Error 0, type: fatal [ 148.816088] {1}[Hardware Error]: section_type: PCIe error [ 148.822391] {1}[Hardware Error]: port_type: 0, PCIe end point [ 148.829026] {1}[Hardware Error]: version: 3.0 [ 148.834266] {1}[Hardware Error]: command: 0x0006, status: 0x0010 [ 148.841140] {1}[Hardware Error]: device_id: 0000:04:00.0 [ 148.847309] {1}[Hardware Error]: slot: 0 [ 148.852077] {1}[Hardware Error]: secondary_bus: 0x00 [ 148.857876] {1}[Hardware Error]: vendor_id: 0x14e4, device_id: 0x165f [ 148.865145] {1}[Hardware Error]: class_code: 020000 [ 148.870845] {1}[Hardware Error]: aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00010000 [ 148.879842] {1}[Hardware Error]: aer_uncor_severity: 0x000ef030 [ 148.886575] {1}[Hardware Error]: TLP Header: 40000001 0000030f 90028090 00000000 [ 148.894823] tg3 0000:04:00.0: AER: aer_status: 0x00100000, aer_mask: 0x00010000 [ 148.902795] tg3 0000:04:00.0: AER: [20] UnsupReq (First) [ 148.910234] tg3 0000:04:00.0: AER: aer_layer=Transaction Layer, aer_agent=Requester ID [ 148.918806] tg3 0000:04:00.0: AER: aer_uncor_severity: 0x000ef030 [ 148.925558] tg3 0000:04:00.0: AER: TLP Header: 40000001 0000030f 90028090 00000000 The MSI is probably raised by incoming packets, so power down the device and disable bus mastering to stop the traffic, as user confirmed this approach works. In addition to that, be extra safe and cancel reset task if it's running. Cc: Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/all/b8db79e6857c41dab4ef08bdf826ea7c47e3bafc.1615947283.git.josef@toxicpanda.com/ BugLink: https://bugs.launchpad.net/bugs/1917471 Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20220826002530.1153296-1-kai.heng.feng@canonical.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jason Wang authored
[ Upstream commit 94553f8a ] The double `like' is duplicated in the comment, remove one. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Rob Clark authored
[ Upstream commit 174974d8 ] If the previous thing cat'ing $debugfs/rd left the FIFO full, then subsequent open could deadlock in rd_write() (because open is blocked, not giving a chance for read() to consume any data in the FIFO). Also it is generally a good idea to clear out old data from the FIFO. Signed-off-by:
Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/496706/ Link: https://lore.kernel.org/r/20220807160901.2353471-2-robdclark@gmail.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jann Horn authored
This is a stable-specific patch. I botched the stable-specific rewrite of commit b67fbebd ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"): As Hugh pointed out, unmap_region() actually operates on a list of VMAs, and the variable "vma" merely points to the first VMA in that list. So if we want to check whether any of the VMAs we're operating on is PFNMAP or MIXEDMAP, we have to iterate through the list and check each VMA. Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Sep 15, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220913140346.422813036@linuxfoundation.org Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
NeilBrown authored
Prior to Linux 5.3, ->transport_lock in sunrpc required the _bh style spinlocks (when not called from a bottom-half handler). When upstream 3848e96e was backported to stable kernels, the spin_lock/unlock calls should have been changed to the _bh version, but this wasn't noted in the patch and didn't happen. So convert these lock/unlock calls to the _bh versions. This patch is required for any stable kernel prior to 5.3 to which the above mentioned patch was backported. Namely 4.9.y, 4.14.y, 4.19.y. Signed-off-by:
NeilBrown <neilb@suse.de> Reported-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Tested-by:
Eugeniu Rosca <erosca@de.adit-jv.com>
-
Yang Ling authored
[ Upstream commit 35508d24 ] The RTCCTRL reg of LS1C is obselete. Writing this reg will cause system hang. Fixes: 60219c56 ("MIPS: Add RTC support for Loongson1C board") Signed-off-by:
Yang Ling <gnaygnil@gmail.com> Tested-by:
Keguang Zhang <keguang.zhang@gmail.com> Acked-by:
Keguang Zhang <keguang.zhang@gmail.com> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Johan Hovold authored
commit 41ca302a upstream. At least one older CH341 appears to have the RX timer enable bit inverted so that setting it disables the RX timer and prevents the FIFO from emptying until it is full. Only set the RX timer enable bit for devices with version newer than 0x27 (even though this probably affects all pre-0x30 devices). Reported-by:
Jonathan Woithe <jwoithe@just42.net> Tested-by:
Jonathan Woithe <jwoithe@just42.net> Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au Fixes: 4e46c410 ("USB: serial: ch341: reinitialize chip on reconfiguration") Cc: stable@vger.kernel.org # 4.10 Signed-off-by:
Johan Hovold <johan@kernel.org> [ johan: backport to 5.4 ] Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit 8e83622a upstream. Disable LCR updates for pre-0x30 devices which use a different (unknown) protocol for line control and where the current register write causes the next received character to be lost. Note that updating LCR using the INIT command has no effect on these devices either. Reported-by:
Jonathan Woithe <jwoithe@just42.net> Tested-by:
Jonathan Woithe <jwoithe@just42.net> Link: https://lore.kernel.org/r/Ys1iPTfiZRWj2gXs@marvin.atrad.com.au Fixes: 4e46c410 ("USB: serial: ch341: reinitialize chip on reconfiguration") Fixes: 55fa15b5 ("USB: serial: ch341: fix baud rate and line-control handling") Cc: stable@vger.kernel.org # 4.10 Signed-off-by:
Johan Hovold <johan@kernel.org> [ johan: adjust context to 4.19 ] Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit d2ac7bef upstream. Generic PHYs must be powered-off before they can be tore down. Similarly, suspending legacy PHYs after having powered them off makes no sense. Fix the dwc3_core_exit() (e.g. called during suspend) and open-coded dwc3_probe() error-path sequences that got this wrong. Note that this makes dwc3_core_exit() match the dwc3_core_init() error path with respect to powering off the PHYs. Fixes: 03c1fd62 ("usb: dwc3: core: add phy cleanup for probe error handling") Fixes: c499ff71 ("usb: dwc3: core: re-factor init and exit paths") Cc: stable@vger.kernel.org # 4.8 Reviewed-by:
Andrew Halaney <ahalaney@redhat.com> Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20220804151001.23612-2-johan+linaro@kernel.org [ johan: adjust context to 4.14 ] Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Toke Høiland-Jørgensen authored
[ Upstream commit 2f09707d ] Cong Wang noticed that the previous fix for sch_sfb accessing the queued skb after enqueueing it to a child qdisc was incomplete: the SFB enqueue function was also calling qdisc_qstats_backlog_inc() after enqueue, which reads the pkt len from the skb cb field. Fix this by also storing the skb len, and using the stored value to increment the backlog after enqueueing. Fixes: 9efd2329 ("sch_sfb: Don't assume the skb is still around after enqueueing to child") Signed-off-by:
Toke Høiland-Jørgensen <toke@toke.dk> Acked-by:
Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20220905192137.965549-1-toke@toke.dk Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Neal Cardwell authored
[ Upstream commit 686dc2db ] Fix a bug reported and analyzed by Nagaraj Arankal, where the handling of a spurious non-SACK RTO could cause a connection to fail to clear retrans_stamp, causing a later RTO to very prematurely time out the connection with ETIMEDOUT. Here is the buggy scenario, expanding upon Nagaraj Arankal's excellent report: (*1) Send one data packet on a non-SACK connection (*2) Because no ACK packet is received, the packet is retransmitted and we enter CA_Loss; but this retransmission is spurious. (*3) The ACK for the original data is received. The transmitted packet is acknowledged. The TCP timestamp is before the retrans_stamp, so tcp_may_undo() returns true, and tcp_try_undo_loss() returns true without changing state to Open (because tcp_is_sack() is false), and tcp_process_loss() returns without calling tcp_try_undo_recovery(). Normally after undoing a CA_Loss episode, tcp_fastretrans_alert() would see that the connection has returned to CA_Open and fall through and call tcp_try_to_open(), which would set retrans_stamp to 0. However, for non-SACK connections we hold the connection in CA_Loss, so do not fall through to call tcp_try_to_open() and do not set retrans_stamp to 0. So retrans_stamp is (erroneously) still non-zero. At this point the first "retransmission event" has passed and been recovered from. Any future retransmission is a completely new "event". However, retrans_stamp is erroneously still set. (And we are still in CA_Loss, which is correct.) (*4) After 16 minutes (to correspond with tcp_retries2=15), a new data packet is sent. Note: No data is transmitted between (*3) and (*4) and we disabled keep alives. The socket's timeout SHOULD be calculated from this point in time, but instead it's calculated from the prior "event" 16 minutes ago (step (*2)). (*5) Because no ACK packet is received, the packet is retransmitted. (*6) At the time of the 2nd retransmission, the socket returns ETIMEDOUT, prematurely, because retrans_stamp is (erroneously) too far in the past (set at the time of (*2)). This commit fixes this bug by ensuring that we reuse in tcp_try_undo_loss() the same careful logic for non-SACK connections that we have in tcp_try_undo_recovery(). To avoid duplicating logic, we factor out that logic into a new tcp_is_non_sack_preventing_reopen() helper and call that helper from both undo functions. Fixes: da34ac76 ("tcp: only undo on partial ACKs in CA_Loss") Reported-by:
Nagaraj Arankal <nagaraj.p.arankal@hpe.com> Link: https://lore.kernel.org/all/SJ0PR84MB1847BE6C24D274C46A1B9B0EB27A9@SJ0PR84MB1847.NAMPRD84.PROD.OUTLOOK.COM/ Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20220903121023.866900-1-ncardwell.kernel@gmail.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
David Lebrun authored
[ Upstream commit 84a53580 ] The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual length of the SECRET attribute, it is possible to provide invalid combinations (e.g., secret = "", secretlen = 64). This case is not checked in the code and with an appropriately crafted netlink message, an out-of-bounds read of up to 64 bytes (max secret length) can occur past the skb end pointer and into skb_shared_info: Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 208 memcpy(hinfo->secret, secret, slen); (gdb) bt #0 seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>, family=<optimized out>) at net/netlink/genetlink.c:731 #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775 #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>) at net/netlink/af_netlink.c:2501 #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) at net/netlink/af_netlink.c:1319 #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>) at net/netlink/af_netlink.c:1345 #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921 ... (gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end $1 = 0xffff88800b1b76c0 (gdb) p/x secret $2 = 0xffff88800b1b76c0 (gdb) p slen $3 = 64 '@' The OOB data can then be read back from userspace by dumping HMAC state. This commit fixes this by ensuring SECRETLEN cannot exceed the actual length of SECRET. Reported-by:
Lucas Leong <wmliang.tw@gmail.com> Tested: verified that EINVAL is correctly returned when secretlen > len(secret) Fixes: 4f4853dc ("ipv6: sr: implement API to control SR HMAC structure") Signed-off-by:
David Lebrun <dlebrun@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-