CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48844 – Bluetooth: hci_core: Fix leaking sent_cmd skb
https://notcve.org/view.php?id=CVE-2022-48844
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix leaking sent_cmd skb sent_cmd memory is not freed before freeing hci_dev causing it to leak it contents. • https://git.kernel.org/stable/c/3679ccc09d8806686d579095ed504e045af7f7d6 https://git.kernel.org/stable/c/9473d06bd1c8da49eafb685aa95a290290c672dd https://git.kernel.org/stable/c/dd3b1dc3dd050f1f47cd13e300732852414270f8 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48843 – drm/vrr: Set VRR capable prop only if it is attached to connector
https://notcve.org/view.php?id=CVE-2022-48843
In the Linux kernel, the following vulnerability has been resolved: drm/vrr: Set VRR capable prop only if it is attached to connector VRR capable property is not attached by default to the connector It is attached only if VRR is supported. So if the driver tries to call drm core set prop function without it being attached that causes NULL dereference. • https://git.kernel.org/stable/c/941e8bcd2b2ba95490738e33dfeca27168452779 https://git.kernel.org/stable/c/0ba557d330946c23559aaea2d51ea649fdeca98a https://git.kernel.org/stable/c/3534c5c005ef99a1804ed50b8a72cdae254cabb5 https://git.kernel.org/stable/c/85271e92ae4f13aa679acaa6cf76b3c36bcb7bab https://git.kernel.org/stable/c/62929726ef0ec72cbbe9440c5d125d4278b99894 •
CVSS: 4.7EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48842 – ice: Fix race condition during interface enslave
https://notcve.org/view.php?id=CVE-2022-48842
In the Linux kernel, the following vulnerability has been resolved: ice: Fix race condition during interface enslave Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating auxiliary device") changes a process of re-creation of aux device so ice_plug_aux_dev() is called from ice_service_task() context. This unfortunately opens a race window that can result in dead-lock when interface has left LAG and immediately enters LAG again. Reproducer: ``` #!/bin/sh ip link add lag0 type bond mode 1 miimon 100 ip link set lag0 for n in {1..10}; do echo Cycle: $n ip link set ens7f0 master lag0 sleep 1 ip link set ens7f0 nomaster done ``` This results in: [20976.208697] Workqueue: ice ice_service_task [ice] [20976.213422] Call Trace: [20976.215871] __schedule+0x2d1/0x830 [20976.219364] schedule+0x35/0xa0 [20976.222510] schedule_preempt_disabled+0xa/0x10 [20976.227043] __mutex_lock.isra.7+0x310/0x420 [20976.235071] enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core] [20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core] [20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core] [20976.261079] ib_register_device+0x40d/0x580 [ib_core] [20976.266139] irdma_ib_register_device+0x129/0x250 [irdma] [20976.281409] irdma_probe+0x2c1/0x360 [irdma] [20976.285691] auxiliary_bus_probe+0x45/0x70 [20976.289790] really_probe+0x1f2/0x480 [20976.298509] driver_probe_device+0x49/0xc0 [20976.302609] bus_for_each_drv+0x79/0xc0 [20976.306448] __device_attach+0xdc/0x160 [20976.310286] bus_probe_device+0x9d/0xb0 [20976.314128] device_add+0x43c/0x890 [20976.321287] __auxiliary_device_add+0x43/0x60 [20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice] [20976.330109] ice_service_task+0xd0c/0xed0 [ice] [20976.342591] process_one_work+0x1a7/0x360 [20976.350536] worker_thread+0x30/0x390 [20976.358128] kthread+0x10a/0x120 [20976.365547] ret_from_fork+0x1f/0x40 ... [20976.438030] task:ip state:D stack: 0 pid:213658 ppid:213627 flags:0x00004084 [20976.446469] Call Trace: [20976.448921] __schedule+0x2d1/0x830 [20976.452414] schedule+0x35/0xa0 [20976.455559] schedule_preempt_disabled+0xa/0x10 [20976.460090] __mutex_lock.isra.7+0x310/0x420 [20976.464364] device_del+0x36/0x3c0 [20976.467772] ice_unplug_aux_dev+0x1a/0x40 [ice] [20976.472313] ice_lag_event_handler+0x2a2/0x520 [ice] [20976.477288] notifier_call_chain+0x47/0x70 [20976.481386] __netdev_upper_dev_link+0x18b/0x280 [20976.489845] bond_enslave+0xe05/0x1790 [bonding] [20976.494475] do_setlink+0x336/0xf50 [20976.502517] __rtnl_newlink+0x529/0x8b0 [20976.543441] rtnl_newlink+0x43/0x60 [20976.546934] rtnetlink_rcv_msg+0x2b1/0x360 [20976.559238] netlink_rcv_skb+0x4c/0x120 [20976.563079] netlink_unicast+0x196/0x230 [20976.567005] netlink_sendmsg+0x204/0x3d0 [20976.570930] sock_sendmsg+0x4c/0x50 [20976.574423] ____sys_sendmsg+0x1eb/0x250 [20976.586807] ___sys_sendmsg+0x7c/0xc0 [20976.606353] __sys_sendmsg+0x57/0xa0 [20976.609930] do_syscall_64+0x5b/0x1a0 [20976.613598] entry_SYSCALL_64_after_hwframe+0x65/0xca 1. Command 'ip link ... set nomaster' causes that ice_plug_aux_dev() is called from ice_service_task() context, aux device is created and associated device->lock is taken. 2. Command 'ip link ... set master...' calls ice's notifier under RTNL lock and that notifier calls ice_unplug_aux_dev(). That function tries to take aux device->lock but this is already taken by ice_plug_aux_dev() in step 1 3. • https://git.kernel.org/stable/c/a9bbacc53d1f5ed8febbfdf31401d20e005f49ef https://git.kernel.org/stable/c/e1014fc5572375658fa421531cedb6e084f477dc https://git.kernel.org/stable/c/5cb1ebdbc4342b1c2ce89516e19808d64417bdbc • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') CWE-667: Improper Locking •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48841 – ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats()
https://notcve.org/view.php?id=CVE-2022-48841
In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats() It is possible to do NULL pointer dereference in routine that updates Tx ring stats. Currently only stats and bytes are updated when ring pointer is valid, but later on ring is accessed to propagate gathered Tx stats onto VSI stats. Change the existing logic to move to next ring when ring is NULL. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige la desreferencia del puntero NULL en ice_update_vsi_tx_ring_stats() Es posible realizar la desreferencia del puntero NULL en la rutina que actualiza las estadísticas del anillo Tx. Actualmente, solo se actualizan las estadísticas y los bytes cuando el puntero del anillo es válido, pero más adelante se accede al anillo para propagar las estadísticas de Tx recopiladas en las estadísticas de VSI. Cambie la lógica existente para pasar al siguiente anillo cuando el anillo sea NULL. • https://git.kernel.org/stable/c/e72bba21355dbb67512a0d666fec9f4b56dbfc2f https://git.kernel.org/stable/c/2397270ec97c5e3009a58ac110a25e1869e9d6ff https://git.kernel.org/stable/c/f153546913bada41a811722f2c6d17c3243a0333 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48840 – iavf: Fix hang during reboot/shutdown
https://notcve.org/view.php?id=CVE-2022-48840
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix hang during reboot/shutdown Recent commit 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") adds a wait-loop at the beginning of iavf_remove() to ensure that port initialization is finished prior unregistering net device. This causes a regression in reboot/shutdown scenario because in this case callback iavf_shutdown() is called and this callback detaches the device, makes it down if it is running and sets its state to __IAVF_REMOVE. Later shutdown callback of associated PF driver (e.g. ice_shutdown) is called. That callback calls among other things sriov_disable() that calls indirectly iavf_remove() (see stack trace below). As the adapter state is already __IAVF_REMOVE then the mentioned loop is end-less and shutdown process hangs. The patch fixes this by checking adapter's state at the beginning of iavf_remove() and skips the rest of the function if the adapter is already in remove state (shutdown is in progress). Reproducer: 1. Create VF on PF driven by ice or i40e driver 2. Ensure that the VF is bound to iavf driver 3. • https://git.kernel.org/stable/c/85aa76066fef64de8a48d0da6b4071ceac455a94 https://git.kernel.org/stable/c/7b9515172ab4d4c6ac0eae4b71013ee6ce932205 https://git.kernel.org/stable/c/80974bb730270199c6fcb189af04d5945b87e813 https://git.kernel.org/stable/c/4477b9a4193b35eb3a8afd2adf2d42add2f88d57 https://git.kernel.org/stable/c/b04683ff8f0823b869c219c78ba0d974bddea0b5 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •