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: 7EXPL: 0CVE-2022-48759 – rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev
https://notcve.org/view.php?id=CVE-2022-48759
In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev struct rpmsg_ctrldev contains a struct cdev. The current code frees the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_ctrldev could be freed before the cdev is entirely released, as in the backtrace below. [ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c [ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0 [ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v [ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26 [ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT) [ 93.730055] Workqueue: events kobject_delayed_cleanup [ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO) [ 93.740216] pc : debug_print_object+0x13c/0x1b0 [ 93.744890] lr : debug_print_object+0x13c/0x1b0 [ 93.749555] sp : ffffffacf5bc7940 [ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000 [ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000 [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000 [ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0 [ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0 [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0 [ 93.785814] x17: 0000000000000000 x16: dfffffd000000000 [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c [ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000 [ 93.802244] x11: 0000000000000001 x10: 0000000000000000 [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900 [ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000 [ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000 [ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001 [ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061 [ 93.835104] Call trace: [ 93.837644] debug_print_object+0x13c/0x1b0 [ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0 [ 93.846987] debug_check_no_obj_freed+0x18/0x20 [ 93.851669] slab_free_freelist_hook+0xbc/0x1e4 [ 93.856346] kfree+0xfc/0x2f4 [ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8 [ 93.864445] device_release+0x84/0x168 [ 93.868310] kobject_cleanup+0x12c/0x298 [ 93.872356] kobject_delayed_cleanup+0x10/0x18 [ 93.876948] process_one_work+0x578/0x92c [ 93.881086] worker_thread+0x804/0xcf8 [ 93.884963] kthread+0x2a8/0x314 [ 93.888303] ret_from_fork+0x10/0x18 The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del(). • https://git.kernel.org/stable/c/c0cdc19f84a4712cf74888f83af286e3c2e14efd https://git.kernel.org/stable/c/74d85e9fbc7022a4011102c7474a9c7aeb704a35 https://git.kernel.org/stable/c/70cb4295ec806b663665e1d2ed15caab6159880e https://git.kernel.org/stable/c/da27b834c1e0222e149e06caddf7718478086d1b https://git.kernel.org/stable/c/1dbb206730f3e5ce90014ad569ddf8167ec4124a https://git.kernel.org/stable/c/85aba11a8ea92a8eef2de95ebbe063086fd62d9c https://git.kernel.org/stable/c/d6cdc6ae542845d4d0ac8b6d99362bde7042a3c7 https://git.kernel.org/stable/c/b7fb2dad571d1e21173c06cef0bced77b •
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 •