deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49603
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ip: Fix data-races around sysctl_ip_fwd_update_priority.

While reading sysctl_ip_fwd_update_priority, it can be changed
concurrently.  Thus, we need to add READ_ONCE() to its readers.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/11038fa781ab916535c53351537b22d6d405667d; https://git.kernel.org/stable/c/351f81f7d7185d18a9ff76f8f8c2fa8c4eea563b; https://git.kernel.org/stable/c/7bf9e18d9a5e99e3c[PII_REDACTED]7e9f047b051e7
CVE: CVE-2022-49604
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ip: Fix data-races around sysctl_ip_fwd_use_pmtu.

While reading sysctl_ip_fwd_use_pmtu, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/60c158dc7b1f0558f6cadd5b50d0386da0000d50; https://git.kernel.org/stable/c/7828309df0f89419a9349761a37c7d1b0da45697; https://git.kernel.org/stable/c/93fbc06da1d819f3981a7bd7928c3641ea67b364
CVE: CVE-2022-49605
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

igc: Reinstate IGC_REMOVED logic and implement it properly

The initially merged version of the igc driver code (via commit
146740f9abc4, "igc: Add support for PF") contained the following
IGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors:

	u32 igc_rd32(struct igc_hw *hw, u32 reg)
	{
		u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
		u32 value = 0;

		if (IGC_REMOVED(hw_addr))
			return ~value;

		value = readl(&hw_addr[reg]);

		/* reads should not return all F's */
		if (!(~value) && (!reg || !(~readl(hw_addr))))
			hw->hw_addr = NULL;

		return value;
	}

And:

	#define wr32(reg, val) \
	do { \
		u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \
		if (!IGC_REMOVED(hw_addr)) \
			writel((val), &hw_addr[(reg)]); \
	} while (0)

E.g. igb has similar checks in its MMIO accessors, and has a similar
macro E1000_REMOVED, which is implemented as follows:

	#define E1000_REMOVED(h) unlikely(!(h))

These checks serve to detect and take note of an 0xffffffff MMIO read
return from the device, which can be caused by a PCIe link flap or some
other kind of PCI bus error, and to avoid performing MMIO reads and
writes from that point onwards.

However, the IGC_REMOVED macro was not originally implemented:

	#ifndef IGC_REMOVED
	#define IGC_REMOVED(a) (0)
	#endif /* IGC_REMOVED */

This led to the IGC_REMOVED logic to be removed entirely in a
subsequent commit (commit 3c215fb18e70, "igc: remove IGC_REMOVED
function"), with the rationale that such checks matter only for
virtualization and that igc does not support virtualization -- but a
PCIe device can become detached even without virtualization being in
use, and without proper checks, a PCIe bus error affecting an igc
adapter will lead to various NULL pointer dereferences, as the first
access after the error will set hw->hw_addr to NULL, and subsequent
accesses will blindly dereference this now-NULL pointer.

This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), and
implements IGC_REMOVED the way it is done for igb, by checking for the
unlikely() case of hw_addr being NULL.  This change prevents the oopses
seen when a PCIe link flap occurs on an igc adapter.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/16cb6717f4f42487ef10583eb8bc98e7d1e33d65; https://git.kernel.org/stable/c/70965b6e5c03aa70cc754af1226b9f9cde0c4bf3; https://git.kernel.org/stable/c/77836dbe35382aaf[PII_REDACTED]c5c89530c77494
CVE: CVE-2022-49606
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/irdma: Fix sleep from invalid context BUG

Taking the qos_mutex to process RoCEv2 QP's on netdev events causes a
kernel splat.

Fix this by removing the handling for RoCEv2 in
irdma_cm_teardown_connections that uses the mutex. This handling is only
needed for iWARP to avoid having connections established while the link is
down or having connections remain functional after the IP address is
removed.

  BUG: sleeping function called from invalid context at kernel/locking/mutex.
  Call Trace:
  kernel: dump_stack+0x66/0x90
  kernel: ___might_sleep.cold.92+0x8d/0x9a
  kernel: mutex_lock+0x1c/0x40
  kernel: irdma_cm_teardown_connections+0x28e/0x4d0 [irdma]
  kernel: ? check_preempt_curr+0x7a/0x90
  kernel: ? select_idle_sibling+0x22/0x3c0
  kernel: ? select_task_rq_fair+0x94c/0xc90
  kernel: ? irdma_exec_cqp_cmd+0xc27/0x17c0 [irdma]
  kernel: ? __wake_up_common+0x7a/0x190
  kernel: irdma_if_notify+0x3cc/0x450 [irdma]
  kernel: ? sched_clock_cpu+0xc/0xb0
  kernel: irdma_inet6addr_event+0xc6/0x150 [irdma]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/2cae7e519032e4b4672cb9204d5586a441924364; https://git.kernel.org/stable/c/a4c5115140ed1833197bad9a6b80265840ff427f; https://git.kernel.org/stable/c/cc0315564d6eec91c716d314b743321be24c70b3
CVE: CVE-2022-49607
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()

Yang Jihing reported a race between perf_event_set_output() and
perf_mmap_close():

	CPU1					CPU2

	perf_mmap_close(e2)
	  if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0
	    detach_rest = true

						ioctl(e1, IOC_SET_OUTPUT, e2)
						  perf_event_set_output(e1, e2)

	  ...
	  list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry)
	    ring_buffer_attach(e, NULL);
	    // e1 isn't yet added and
	    // therefore not detached

						    ring_buffer_attach(e1, e2->rb)
						      list_add_rcu(&e1->rb_entry,
								   &e2->rb->event_list)

After this; e1 is attached to an unmapped rb and a subsequent
perf_mmap() will loop forever more:

	again:
		mutex_lock(&e->mmap_mutex);
		if (event->rb) {
			...
			if (!atomic_inc_not_zero(&e->rb->mmap_count)) {
				...
				mutex_unlock(&e->mmap_mutex);
				goto again;
			}
		}

The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach
in perf_event_set_output() holds e1->mmap_mutex. As such there is no
serialization to avoid this race.

Change perf_event_set_output() to take both e1->mmap_mutex and
e2->mmap_mutex to alleviate that problem. Additionally, have the loop
in perf_mmap() detach the rb directly, this avoids having to wait for
the concurrent perf_mmap_close() to get around to doing it to make
progress.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/17f[PII_REDACTED]517ee9bbd6511249e5310e5617c; https://git.kernel.org/stable/c/3bbd868099287ff9027db59029b502fcfa2202a0; https://git.kernel.org/stable/c/43128b3eee337824158f34da6648163d2f2fb937
CVE: CVE-2022-49608
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: ralink: Check for null return of devm_kcalloc

Because of the possible failure of the allocation, data->domains might
be NULL pointer and will cause the dereference of the NULL pointer
later.
Therefore, it might be better to check it and directly return -ENOMEM
without releasing data manually if fails, because the comment of the
devm_kmalloc() says "Memory allocated with this function is
automatically freed on driver detach.".
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/13596e6c9e541e90e5fc2c52b23f08b951370da9; https://git.kernel.org/stable/c/44016a85419ca0d4f1e4d0127b330f8e4e2a57d0; https://git.kernel.org/stable/c/5595d30c4dc27d939635c3188c68203b6ece1711
CVE: CVE-2022-49609
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

power/reset: arm-versatile: Fix refcount leak in versatile_reboot_probe

of_find_matching_node_and_match() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/493ceca3271316e74639c89ff8ac35883de64256; https://git.kernel.org/stable/c/49fa778ee044b00471dd9ccae5f6a121fffea1ac; https://git.kernel.org/stable/c/6689754b121bd487f[PII_REDACTED]2b3a5cd7374af
CVE: CVE-2022-49610
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: VMX: Prevent RSB underflow before vmenter

On VMX, there are some balanced returns between the time the guest's
SPEC_CTRL value is written, and the vmenter.

Balanced returns (matched by a preceding call) are usually ok, but it's
at least theoretically possible an NMI with a deep call stack could
empty the RSB before one of the returns.

For maximum paranoia, don't allow *any* returns (balanced or otherwise)
between the SPEC_CTRL write and the vmenter.

  [ bp: Fix 32-bit build. ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/07853adc29a058c5fd143c14e5ac528448a72ed9; https://git.kernel.org/stable/c/afd743f6dde87296c6f[PII_REDACTED]c491bb85862
CVE: CVE-2022-49611
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/speculation: Fill RSB on vmexit for IBRS

Prevent RSB underflow/poisoning attacks with RSB.  While at it, add a
bunch of comments to attempt to document the current state of tribal
knowledge about RSB attacks and what exactly is being mitigated.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/17a9fc4a7b91f[PII_REDACTED]bb6ae6416bc0de1c0; https://git.kernel.org/stable/c/3d323b99ff5c8c[PII_REDACTED]6d65f6af5b0479d8; https://git.kernel.org/stable/c/4d7f72b6e1bc630bec7e4cd51814bc2b092bf153
CVE: CVE-2022-49612
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

power: supply: core: Fix boundary conditions in interpolation

The functions power_supply_temp2resist_simple and power_supply_ocv2cap_simple
handle boundary conditions incorrectly.
The change was introduced in a4585ba2050f460f749bbaf2b67bd56c41e30283
("power: supply: core: Use library interpolation").
There are two issues: First, the lines "high = i - 1" and "high = i" in ocv2cap
have the wrong order compared to temp2resist. As a consequence, ocv2cap
sets high=-1 if ocv>table[0].ocv, which causes an out-of-bounds read.
Second, the logic of temp2resist is also not correct.
Consider the case table[] = {{20, 100}, {10, 80}, {0, 60}}.
For temp=5, we expect a resistance of 70% by interpolation.
However, temp2resist sets high=low=2 and returns 60.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/093d27bb6f2d1963f927ef59c9a2d[PII_REDACTED]6; https://git.kernel.org/stable/c/a762cee5d933fe4e2e1b773d60fc74fb8248d8c4
CVE: CVE-2022-49613
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: 8250: Fix PM usage_count for console handover

When console is enabled, univ8250_console_setup() calls
serial8250_console_setup() before .dev is set to uart_port. Therefore,
it will not call pm_runtime_get_sync(). Later, when the actual driver
is going to take over univ8250_console_exit() is called. As .dev is
already set, serial8250_console_exit() makes pm_runtime_put_sync() call
with usage count being zero triggering PM usage count warning
(extra debug for univ8250_console_setup(), univ8250_console_exit(), and
serial8250_register_ports()):

[    0.068987] univ8250_console_setup ttyS0 nodev
[    0.499670] printk: console [ttyS0] enabled
[    0.717955] printk: console [ttyS0] printing thread started
[    1.960163] serial8250_register_ports assigned dev for ttyS0
[    1.976830] printk: console [ttyS0] disabled
[    1.976888] printk: console [ttyS0] printing thread stopped
[    1.977073] univ8250_console_exit ttyS0 usage:0
[    1.977075] serial8250 serial8250: Runtime PM usage count underflow!
[    1.977429] dw-apb-uart.6: ttyS0 at MMIO 0x[PII_REDACTED] (irq = 33, base_baud = 115200) is a 16550A
[    1.977812] univ8250_console_setup ttyS0 usage:2
[    1.978167] printk: console [ttyS0] printing thread started
[    1.978203] printk: console [ttyS0] enabled

To fix the issue, call pm_runtime_get_sync() in
serial8250_register_ports() as soon as .dev is set for an uart_port
if it has console enabled.

This problem became apparent only recently because 82586a721595 ("PM:
runtime: Avoid device usage count underflows") added the warning
printout. I confirmed this problem also occurs with v5.18 (w/o the
warning printout, obviously).
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/190ce5cdc55d1b66ea582ac2be6fd5a72e3cc486; https://git.kernel.org/stable/c/5df66302f03f87ae8953785a882d78e911f00c55; https://git.kernel.org/stable/c/d9cb6fabc90102f9e61fe35bd0160db88f4f53b4
CVE: CVE-2022-49614
Published: 2025-02-26
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2022-49615
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error

The initial settings will be written before the codec probe function.
But, the rt711->component doesn't be assigned yet.
If IO error happened during initial settings operations, it will cause the kernel panic.
This patch changed component->dev to slave->dev to fix this issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1df793d479bef546569fc2e409ff8bb3f0fb8e99; https://git.kernel.org/stable/c/269be8b2907378adf72d7347cfa43ef230351a06; https://git.kernel.org/stable/c/7bb71133cae88d3003a3490b97864af76533072b
CVE: CVE-2022-49616
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: rt7*-sdw: harden jack_detect_handler

Realtek headset codec drivers typically check if the card is
instantiated before proceeding with the jack detection.

The rt700, rt711 and rt711-sdca are however missing a check on the
card pointer, which can lead to NULL dereferences encountered in
driver bind/unbind tests.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0484271ab0ce50649329fa9dc23c50853c5b26a4; https://git.kernel.org/stable/c/07a606e1389a63b61cb8cd591026f[PII_REDACTED]3; https://git.kernel.org/stable/c/1d75b73ec6d6b705cca528b36d8315e43e8d7fa5
CVE: CVE-2022-49617
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: Intel: sof_sdw: handle errors on card registration

If the card registration fails, typically because of deferred probes,
the device properties added for headset codecs are not removed, which
leads to kernel oopses in driver bind/unbind tests.

We already clean-up the device properties when the card is removed,
this code can be moved as a helper and called upon card registration
errors.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/09bca0ffc95c50369f1345d80ecfaca51864126f; https://git.kernel.org/stable/c/f2556ce6b35ae0fc72000a4daa21ded12665e2f2; https://git.kernel.org/stable/c/fe154c4ff376bc31041c6441958a08243df09c99
CVE: CVE-2022-49618
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux()

pdesc could be null but still dereference pdesc->name and it will lead to
a null pointer access. So we move a null check before dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/3cb392b64304a05bf647e2e44efacd9a1f3c3c6a; https://git.kernel.org/stable/c/84a85d3fef2e75b1fe9fc2af6f[PII_REDACTED]a1ed; https://git.kernel.org/stable/c/e162a24f1dd06c0dcae71f2565c9f3da2827b98e
CVE: CVE-2022-49619
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: sfp: fix memory leak in sfp_probe()

sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When
devm_add_action() fails, sfp is not freed, which leads to a memory leak.

We should use devm_add_action_or_reset() instead of devm_add_action().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0a18d802d65cf662644fd1d369c86d84a5630652; https://git.kernel.org/stable/c/1545bc727625ea6e8decd717e5d1e8cc704ccf8f; https://git.kernel.org/stable/c/204543581a2f26bb3b997a304c0bd06926ba7f15
CVE: CVE-2022-49620
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: tipc: fix possible refcount leak in tipc_sk_create()

Free sk in case tipc_sk_insert() fails.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/00aff3590fc0a73bddd3b743863c14e76fd35c0c; https://git.kernel.org/stable/c/3b2957fc09fe1ac7f07f40dd50dd5f93e3f3a7a2; https://git.kernel.org/stable/c/4919d82f7041157a421ca9bf39a78551d5ad8a1b
CVE: CVE-2022-49621
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

cpufreq: pmac32-cpufreq: Fix refcount leak bug

In pmac_cpufreq_init_MacRISC3(), we need to add corresponding
of_node_put() for the three node pointers whose refcount have
been incremented by of_find_node_by_name().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/37c16fc2cb13a13f3c0193bfc6f2edef7d7df7d7; https://git.kernel.org/stable/c/3ea9dbf7c2f436952bca331c6f5d72f75aca224e; https://git.kernel.org/stable/c/4513018d0bd739097570d26a7760551cba3deb56
CVE: CVE-2022-49622
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: avoid skb access on nf_stolen

When verdict is NF_STOLEN, the skb might have been freed.

When tracing is enabled, this can result in a use-after-free:
1. access to skb->nf_trace
2. access to skb->mark
3. computation of trace id
4. dump of packet payload

To avoid 1, keep a cached copy of skb->nf_trace in the
trace state struct.
Refresh this copy whenever verdict is != STOLEN.

Avoid 2 by skipping skb->mark access if verdict is STOLEN.

3 is avoided by precomputing the trace id.

Only dump the packet when verdict is not "STOLEN".
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0016d5d46d7440729a3132f61a8da3bf7f84e2ba; https://git.kernel.org/stable/c/e34b9ed96ce3b06c79bf884009b16961ca478f87
CVE: CVE-2022-49624
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: atlantic: remove aq_nic_deinit() when resume

aq_nic_deinit() has been called while suspending, so we don't have to call
it again on resume.
Actually, call it again leads to another hang issue when resuming from
S3.

Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992345] Call Trace:
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992346] <TASK>
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992348] aq_nic_deinit+0xb4/0xd0 [atlantic]
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992356] aq_pm_thaw+0x7f/0x100 [atlantic]
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992362] pci_pm_resume+0x5c/0x90
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992366] ? pci_pm_thaw+0x80/0x80
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992368] dpm_run_callback+0x4e/0x120
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992371] device_resume+0xad/0x200
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992373] async_resume+0x1e/0x40
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992374] async_run_entry_fn+0x33/0x120
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992377] process_one_work+0x220/0x3c0
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992380] worker_thread+0x4d/0x3f0
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992382] ? process_one_work+0x3c0/0x3c0
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992384] kthread+0x12a/0x150
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992386] ? set_kthread_struct+0x40/0x40
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992387] ret_from_fork+0x22/0x30
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992391] </TASK>
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992392] ---[ end trace 1ec8c79604ed5e0d ]---
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992394] PM: dpm_run_callback(): pci_pm_resume+0x0/0x90 returns -110
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992397] atlantic 0000:02:00.0: PM: failed to resume async: error -110
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2e15c51fefaffaf9f72255eaef4fada05055e4c5; https://git.kernel.org/stable/c/58c90993933e7a76305519bc70da8c0cd2907c1f; https://git.kernel.org/stable/c/702419db7ded2e3686fbc05040b61d7428d611d5
CVE: CVE-2022-49625
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

sfc: fix kernel panic when creating VF

When creating VFs a kernel panic can happen when calling to
efx_ef10_try_update_nic_stats_vf.

When releasing a DMA coherent buffer, sometimes, I don't know in what
specific circumstances, it has to unmap memory with vunmap. It is
disallowed to do that in IRQ context or with BH disabled. Otherwise, we
hit this line in vunmap, causing the crash:
  BUG_ON(in_interrupt());

This patch reenables BH to release the buffer.

Log messages when the bug is hit:
 kernel BUG at mm/vmalloc.c:2727!
 invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G          I      --------- ---  5.14.0-119.el9.x86_64 #1
 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020
 RIP: 0010:vunmap+0x2e/0x30
 ...skip...
 Call Trace:
  __iommu_dma_free+0x96/0x100
  efx_nic_free_buffer+0x2b/0x40 [sfc]
  efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc]
  efx_ef10_update_stats_vf+0x18/0x40 [sfc]
  efx_start_all+0x15e/0x1d0 [sfc]
  efx_net_open+0x5a/0xe0 [sfc]
  __dev_open+0xe7/0x1a0
  __dev_change_flags+0x1d7/0x240
  dev_change_flags+0x21/0x60
  ...skip...
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/16662524ec5da801fb78a1afcaf6e782f1cf103a; https://git.kernel.org/stable/c/68e5f32f0de9594629ff9e599294d9801c6187de; https://git.kernel.org/stable/c/82bcb730f856086f033e6c04082eb4503d4c2fa4