CVSS: 5.3EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48761 – usb: xhci-plat: fix crash when suspend if remote wake enable
https://notcve.org/view.php?id=CVE-2022-48761
In the Linux kernel, the following vulnerability has been resolved: usb: xhci-plat: fix crash when suspend if remote wake enable Crashed at i.mx8qm platform when suspend if enable remote wakeup Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12 Hardware name: Freescale i.MX8QM MEK (DT) Workqueue: events_unbound async_run_entry_fn pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8 lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8 sp : ffff80001394bbf0 x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578 x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000 x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001 x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0 x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453 x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620 Call trace: xhci_disable_hub_port_wake.isra.62+0x60/0xf8 xhci_suspend+0x58/0x510 xhci_plat_suspend+0x50/0x78 platform_pm_suspend+0x2c/0x78 dpm_run_callback.isra.25+0x50/0xe8 __device_suspend+0x108/0x3c0 The basic flow: 1. run time suspend call xhci_suspend, xhci parent devices gate the clock. 2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend 3. xhci_suspend call xhci_disable_hub_port_wake, which access register, but clock already gated by run time suspend. This problem was hidden by power domain driver, which call run time resume before it. But the below commit remove it and make this issue happen. commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()") This patch call run time resume before suspend to make sure clock is on before access register. Testeb-by: Abel Vesa <abel.vesa@nxp.com> • https://git.kernel.org/stable/c/20c51a4c52208f98e27308c456a1951778f41fa5 https://git.kernel.org/stable/c/d5755832a1e47f5d8773f0776e211ecd4e02da72 https://git.kernel.org/stable/c/8b05ad29acb972850ad795fa850e814b2e758b83 https://git.kernel.org/stable/c/9df478463d9feb90dae24f183383961cf123a0ec •
CVSS: 4.1EPSS: 0%CPEs: 9EXPL: 0CVE-2022-48760 – USB: core: Fix hang in usb_kill_urb by adding memory barriers
https://notcve.org/view.php?id=CVE-2022-48760
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix hang in usb_kill_urb by adding memory barriers The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. • https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427 https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0 https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3 https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6 https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193 https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26 https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d4099 • CWE-820: Missing Synchronization •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2022-48758 – scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()
https://notcve.org/view.php?id=CVE-2022-48758
In the Linux kernel, the following vulnerability has been resolved: scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put() The bnx2fc_destroy() functions are removing the interface before calling destroy_work. This results multiple WARNings from sysfs_remove_group() as the controller rport device attributes are removed too early. Replace the fcoe_port's destroy_work queue. It's not needed. The problem is easily reproducible with the following steps. Example: $ dmesg -w & $ systemctl enable --now fcoe $ fipvlan -s -c ens2f1 $ fcoeadm -d ens2f1.802 [ 583.464488] host2: libfc: Link down on port (7500a1) [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!! [ 583.490468] ------------[ cut here ]------------ [ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0' [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80 [ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ... [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1 [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc] [ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80 [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ... [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282 [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000 [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0 [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00 [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400 [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004 [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000 [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0 [ 584.454888] Call Trace: [ 584.466108] device_del+0xb2/0x3e0 [ 584.481701] device_unregister+0x13/0x60 [ 584.501306] bsg_unregister_queue+0x5b/0x80 [ 584.522029] bsg_remove_queue+0x1c/0x40 [ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc] [ 584.573823] process_one_work+0x1e3/0x3b0 [ 584.592396] worker_thread+0x50/0x3b0 [ 584.609256] ? rescuer_thread+0x370/0x370 [ 584.628877] kthread+0x149/0x170 [ 584.643673] ? • https://git.kernel.org/stable/c/0cbf32e1681d870632a1772601cbaadd996dc978 https://git.kernel.org/stable/c/2a12fe8248a38437b95b942bbe85aced72e6e2eb https://git.kernel.org/stable/c/262550f29c750f7876b6ed1244281e72b64ebffb https://git.kernel.org/stable/c/c93a290c862ccfa404e42d7420565730d67cbff9 https://git.kernel.org/stable/c/de6336b17a1376db1c0f7a528cce8783db0881c0 https://git.kernel.org/stable/c/bf2bd892a0cb14dd2d21f2c658f4b747813be311 https://git.kernel.org/stable/c/00849de10f798a9538242824a51b1756e7110754 https://git.kernel.org/stable/c/b11e34f7bab21df36f02a5e54fb69e858 •
CVSS: 3.3EPSS: 0%CPEs: 9EXPL: 0CVE-2022-48757 – net: fix information leakage in /proc/net/ptype
https://notcve.org/view.php?id=CVE-2022-48757
In the Linux kernel, the following vulnerability has been resolved: net: fix information leakage in /proc/net/ptype In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new `packet_type` added by this packet socket by reading `/proc/net/ptype` file. This is minor information leakage as packet socket is namespace aware. Add a net pointer in `packet_type` to keep the net namespace of of corresponding packet socket. In `ptype_seq_show`, this net pointer must be checked when it is not NULL. • https://git.kernel.org/stable/c/2feb27dbe00cbb4f7d31f90acf6bd0d751dd0a50 https://git.kernel.org/stable/c/8f88c78d24f6f346919007cd459fd7e51a8c7779 https://git.kernel.org/stable/c/be1ca30331c7923c6f376610c1bd6059be9b1908 https://git.kernel.org/stable/c/c38023032a598ec6263e008d62c7f02def72d5c7 https://git.kernel.org/stable/c/b67ad6170c0ea87391bb253f35d1f78857736e54 https://git.kernel.org/stable/c/e372ecd455b6ebc7720f52bf4b5f5d44d02f2092 https://git.kernel.org/stable/c/db044d97460ea792110eb8b971e82569ded536c6 https://git.kernel.org/stable/c/e43669c77cb3a742b7d84ecdc7c68c416 • CWE-276: Incorrect Default Permissions •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48756 – drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
https://notcve.org/view.php?id=CVE-2022-48756
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Addresses-Coverity-ID: 1493860 ("Null pointer dereference") • https://git.kernel.org/stable/c/5c8290284402bf7d2c12269402b3177b899c78b7 https://git.kernel.org/stable/c/6d9f8ba28f3747ca0f910a363e46f1114856dbbe https://git.kernel.org/stable/c/ca63eeb70fcb53c42e1fe54e1735a54d8e7759fd https://git.kernel.org/stable/c/581317b1f001b7509041544d7019b75571daa100 https://git.kernel.org/stable/c/79c0b5287ded74f4eacde4dfd8aa0a76cbd853b5 https://git.kernel.org/stable/c/56480fb10b976581a363fd168dc2e4fbee87a1a7 https://git.kernel.org/stable/c/2b7e7df1eacd280e561ede3e977853606871c951 https://git.kernel.org/stable/c/5e761a2287234bc402ba7ef07129f5103 •