deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-49980
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

vrf: revert "vrf: Remove unnecessary RCU-bh critical section"

This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.

dev_queue_xmit_nit is expected to be called with BH disabled.
__dev_queue_xmit has the following:

        /* Disable soft irqs for various locks below. Also
         * stops preemption for RCU.
         */
        rcu_read_lock_bh();

VRF must follow this invariant. The referenced commit removed this
protection. Which triggered a lockdep warning:

	================================
	WARNING: inconsistent lock state
	6.11.0 #1 Tainted: G        W
	--------------------------------
	inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
	btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes:
	ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30
	{IN-SOFTIRQ-W} state was registered at:
	  lock_acquire+0x19a/0x4f0
	  _raw_spin_lock+0x27/0x40
	  packet_rcv+0xa33/0x1320
	  __netif_receive_skb_core.constprop.0+0xcb0/0x3a90
	  __netif_receive_skb_list_core+0x2c9/0x890
	  netif_receive_skb_list_internal+0x610/0xcc0
          [...]

	other info that might help us debug this:
	 Possible unsafe locking scenario:

	       CPU0
	       ----
	  lock(rlock-AF_PACKET);
	  <Interrupt>
	    lock(rlock-AF_PACKET);

	 *** DEADLOCK ***

	Call Trace:
	 <TASK>
	 dump_stack_lvl+0x73/0xa0
	 mark_lock+0x102e/0x16b0
	 __lock_acquire+0x9ae/0x6170
	 lock_acquire+0x19a/0x4f0
	 _raw_spin_lock+0x27/0x40
	 tpacket_rcv+0x863/0x3b30
	 dev_queue_xmit_nit+0x709/0xa40
	 vrf_finish_direct+0x26e/0x340 [vrf]
	 vrf_l3_out+0x5f4/0xe80 [vrf]
	 __ip_local_out+0x51e/0x7a0
          [...]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/718a752bd746b3f4dd62516bb437baf73d548415; https://git.kernel.org/stable/c/8c9381b3138246d46536db93ed696832abd70204; https://git.kernel.org/stable/c/b04c4d9eb4f25b950b33218e33b04c94e7445e51
CVE: CVE-2024-49981
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

media: venus: fix use after free bug in venus_remove due to race condition

in venus_probe, core->work is bound with venus_sys_error_handler, which is
used to handle error. The code use core->sys_err_done to make sync work.
The core->work is started in venus_event_notify.

If we call venus_remove, there might be an unfished work. The possible
sequence is as follows:

CPU0                  CPU1

                     |venus_sys_error_handler
venus_remove         |
hfi_destroy	 		 |
venus_hfi_destroy	 |
kfree(hdev);	     |
                     |hfi_reinit
					 |venus_hfi_queues_reinit
                     |//use hdev

Fix it by canceling the work in venus_remove.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-416
References: https://git.kernel.org/stable/c/10941d4f99a5a34999121b314afcd9c0a1c14f15; https://git.kernel.org/stable/c/2a541fcc0bd2b05a458e9613376df1289ec11621; https://git.kernel.org/stable/c/5098b9e6377577fe13d03e1d8914930f014a3314
CVE: CVE-2024-49982
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

aoe: fix the potential use-after-free problem in more places

For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential
use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put()
instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs
into use-after-free.

Then Nicolai Stange found more places in aoe have potential use-after-free
problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe()
and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push
packet to tx queue. So they should also use dev_hold() to increase the
refcnt of skb->dev.

On the other hand, moving dev_put() to tx() causes that the refcnt of
skb->dev be reduced to a negative value, because corresponding
dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(),
probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/07b418d50ccbbca7e5d87a3a0d41d436cefebf79; https://git.kernel.org/stable/c/12f7b89dd72b25da4eeaa[PII_REDACTED]3cad6418e; https://git.kernel.org/stable/c/6d6e54fc71ad1ab0a87047fd9c211e75d86084a3
CVE: CVE-2024-49983
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free

When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(),
the 'ppath' is updated but it is the 'path' that is freed, thus potentially
triggering a double-free in the following process:

ext4_ext_replay_update_ex
  ppath = path
  ext4_force_split_extent_at(&ppath)
    ext4_split_extent_at
      ext4_ext_insert_extent
        ext4_ext_create_new_leaf
          ext4_ext_grow_indepth
            ext4_find_extent
              if (depth > path[0].p_maxdepth)
                kfree(path)                 ---> path First freed
                *orig_path = path = NULL    ---> null ppath
  kfree(path)                               ---> path double-free !!!

So drop the unnecessary ppath and use path directly to avoid this problem.
And use ext4_find_extent() directly to update path, avoiding unnecessary
memory allocation and freeing. Also, propagate the error returned by
ext4_find_extent() instead of using strange error codes.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/1b558006d98b7b0b730027be0ee98973dd10ee0d; https://git.kernel.org/stable/c/3ff710662e8d86a63a39b334e9ca0cb10e5c14b0; https://git.kernel.org/stable/c/5c0f4cc84d3a601c99bc5e6e6eb1cbda542cce95
CVE: CVE-2024-49984
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Prevent out of bounds access in performance query extensions

Check that the number of perfmons userspace is passing in the copy and
reset extensions is not greater than the internal kernel storage where
the ids will be copied into.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/3e50d72abe50204c7b19784a66e86da29dde32c2; https://git.kernel.org/stable/c/d9536f16be3970c170571efa707c13cd089c774e; https://git.kernel.org/stable/c/f32b5128d2c440368b5bf3a7a356823e235caabb
CVE: CVE-2024-49985
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume

In case there is any sort of clock controller attached to this I2C bus
controller, for example Versaclock or even an AIC32x4 I2C codec, then
an I2C transfer triggered from the clock controller clk_ops .prepare
callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.

This is because the clock controller first grabs the prepare_lock mutex
and then performs the prepare operation, including its I2C access. The
I2C access resumes this I2C bus controller via .runtime_resume callback,
which calls clk_prepare_enable(), which attempts to grab the prepare_lock
mutex again and deadlocks.

Since the clock are already prepared since probe() and unprepared in
remove(), use simple clk_enable()/clk_disable() calls to enable and
disable the clock on runtime suspend and resume, to avoid hitting the
prepare_lock mutex.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/048bbbdbf85e5e00258dfb12f5e368f908801d7b; https://git.kernel.org/stable/c/1883cad2cc629ded4a3556c0bbb8b42533ad8764; https://git.kernel.org/stable/c/22a1f8a5b56ba93d3e8b7a1dafa24e01c8bb48ba
CVE: CVE-2024-49986
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors

x86_android_tablet_remove() frees the pdevs[] array, so it should not
be used after calling x86_android_tablet_remove().

When platform_device_register() fails, store the pdevs[x] PTR_ERR() value
into the local ret variable before calling x86_android_tablet_remove()
to avoid using pdevs[] after it has been freed.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2fae3129c0c08e72b1fe93e61fd8fd203252094a; https://git.kernel.org/stable/c/73a98cf79e4dbfa3d0c363e826c65aae089b313c; https://git.kernel.org/stable/c/aac871e493fc8809e60209d9899b1af07e9dbfc8
CVE: CVE-2024-49987
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

bpftool: Fix undefined behavior in qsort(NULL, 0, ...)

When netfilter has no entry to display, qsort is called with
qsort(NULL, 0, ...). This results in undefined behavior, as UBSan
reports:

net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null

Although the C standard does not explicitly state whether calling qsort
with a NULL pointer when the size is 0 constitutes undefined behavior,
Section 7.1.4 of the C standard (Use of library functions) mentions:

"Each of the following statements applies unless explicitly stated
otherwise in the detailed descriptions that follow: If an argument to a
function has an invalid value (such as a value outside the domain of
the function, or a pointer outside the address space of the program, or
a null pointer, or a pointer to non-modifiable storage when the
corresponding parameter is not const-qualified) or a type (after
promotion) not expected by a function with variable number of
arguments, the behavior is undefined."

To avoid this, add an early return when nf_link_info is NULL to prevent
calling qsort with a NULL pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2e0f6f33f2aa87493b365a38a8fd87b8854b7734; https://git.kernel.org/stable/c/c208b02827eb642758cef65641995fd3f38c89af; https://git.kernel.org/stable/c/c2d9f9a7837ab29ccae0c42252f17d436bf0a501
CVE: CVE-2024-49988
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: add refcnt to ksmbd_conn struct

When sending an oplock break request, opinfo->conn is used,
But freed ->conn can be used on multichannel.
This patch add a reference count to the ksmbd_conn struct
so that it can be freed when it is no longer used.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/18f06bacc197d4ac9b518ad1c69999bc3d83e7aa; https://git.kernel.org/stable/c/9fd3cde4628bcd3549ab95061f2bab74d2ed4f3b; https://git.kernel.org/stable/c/e9dac92f4482a382e8c0fe1bc243da5fc3526b0c
CVE: CVE-2024-49989
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix double free issue during amdgpu module unload

Flexible endpoints use DIGs from available inflexible endpoints,
so only the encoders of inflexible links need to be freed.
Otherwise, a double free issue may occur when unloading the
amdgpu module.

[  279.190523] RIP: 0010:__slab_free+0x152/0x2f0
[  279.190577] Call Trace:
[  279.190580]  <TASK>
[  279.190582]  ? show_regs+0x69/0x80
[  279.190590]  ? die+0x3b/0x90
[  279.190595]  ? do_trap+0xc8/0xe0
[  279.190601]  ? do_error_trap+0x73/0xa0
[  279.190605]  ? __slab_free+0x152/0x2f0
[  279.190609]  ? exc_invalid_op+0x56/0x70
[  279.190616]  ? __slab_free+0x152/0x2f0
[  279.190642]  ? asm_exc_invalid_op+0x1f/0x30
[  279.190648]  ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
[  279.191096]  ? __slab_free+0x152/0x2f0
[  279.191102]  ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
[  279.191469]  kfree+0x260/0x2b0
[  279.191474]  dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
[  279.191821]  link_destroy+0xd7/0x130 [amdgpu]
[  279.192248]  dc_destruct+0x90/0x270 [amdgpu]
[  279.192666]  dc_destroy+0x19/0x40 [amdgpu]
[  279.193020]  amdgpu_dm_fini+0x16e/0x200 [amdgpu]
[  279.193432]  dm_hw_fini+0x26/0x40 [amdgpu]
[  279.193795]  amdgpu_device_fini_hw+0x24c/0x400 [amdgpu]
[  279.194108]  amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu]
[  279.194436]  amdgpu_pci_remove+0x40/0x80 [amdgpu]
[  279.194632]  pci_device_remove+0x3a/0xa0
[  279.194638]  device_remove+0x40/0x70
[  279.194642]  device_release_driver_internal+0x1ad/0x210
[  279.194647]  driver_detach+0x4e/0xa0
[  279.194650]  bus_remove_driver+0x6f/0xf0
[  279.194653]  driver_unregister+0x33/0x60
[  279.194657]  pci_unregister_driver+0x44/0x90
[  279.194662]  amdgpu_exit+0x19/0x1f0 [amdgpu]
[  279.194939]  __do_sys_delete_module.isra.0+0x198/0x2f0
[  279.194946]  __x64_sys_delete_module+0x16/0x20
[  279.194950]  do_syscall_64+0x58/0x120
[  279.194954]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[  279.194980]  </TASK>
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/20b5a8f9f4670a8503aa9fa95ca632e77c6bf55d; https://git.kernel.org/stable/c/3c0ff4de45ce2c5f7997a1ffa6eefee4b79e6b58; https://git.kernel.org/stable/c/43c296870740a3a264cdca9f18db12e12e9cfbdb
CVE: CVE-2024-49990
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/hdcp: Check GSC structure validity

Sometimes xe_gsc is not initialized when checked at HDCP capability
check. Add gsc structure check to avoid null pointer error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/7266a424b1e[PII_REDACTED]22e3c27f697d12de627; https://git.kernel.org/stable/c/b4224f6bae3801d589f815672ec62800a1501b0d; https://git.kernel.org/stable/c/c940627857eedca8407b84b40ceb4252b100d291
CVE: CVE-2024-49991
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer

Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,
otherwise amdgpu_bo_unref clear the local variable, the original pointer
not set to NULL, this could cause use-after-free bug.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/30ceb873cc2e97348d9da2265b2d1ddf07f682e1; https://git.kernel.org/stable/c/6c[PII_REDACTED]807e4e3be9a23df8ee[PII_REDACTED]; https://git.kernel.org/stable/c/71f3240f82987f0f070ea5bed559033de7d4c0e1
CVE: CVE-2024-49992
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/stm: Avoid use-after-free issues with crtc and plane

ltdc_load() calls functions drm_crtc_init_with_planes(),
drm_universal_plane_init() and drm_encoder_init(). These functions
should not be called with parameters allocated with devm_kzalloc()
to avoid use-after-free issues [1].

Use allocations managed by the DRM framework.

Found by Linux Verification Center (linuxtesting.org).

[1]
https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0a1741d10da29aa84955ef89ae9a03c4b6038657; https://git.kernel.org/stable/c/19dd9780b7ac673be95bf6fd6892a184c9db611f; https://git.kernel.org/stable/c/454e5d7e671946698af0f201e48469e5ddb42851
CVE: CVE-2024-49993
Published: 2024-10-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-49994
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

block: fix integer overflow in BLKSECDISCARD

I independently rediscovered

	commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
	block: fix overflow in blk_ioctl_discard()

but for secure erase.

Same problem:

	uint64_t r[2] = {512,[PII_REDACTED][PII_REDACTED]ULL};
	ioctl(fd, BLKSECDISCARD, r);

will enter near infinite loop inside blkdev_issue_secure_erase():

	a.out: attempt to access beyond end of device
	loop0: rw=5, sector=[PII_REDACTED], nr_sectors = 1024 limit=2048
	bio_check_eod: 3286214 callbacks suppressed
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/0842ddd83939eb4db940b9af7d39e79722bc41aa; https://git.kernel.org/stable/c/697ba0b6ec4ae04afb67d3911799b5e2043b4455; https://git.kernel.org/stable/c/6c9915fa9410cbb9bd75ee283c03120046c56d3d
CVE: CVE-2024-49995
Published: 2024-10-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-49996
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix buffer overflow when parsing NFS reparse points

ReparseDataLength is sum of the InodeType size and DataBuffer size.
So to get DataBuffer size it is needed to subtract InodeType's size from
ReparseDataLength.

Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer
at position after the end of the buffer because it does not subtract
InodeType size from the length. Fix this problem and correctly subtract
variable len.

Member InodeType is present only when reparse buffer is large enough. Check
for ReparseDataLength before accessing InodeType to prevent another invalid
memory access.

Major and minor rdev values are present also only when reparse buffer is
large enough. Check for reparse buffer size before calling reparse_mkdev().
CVSS Score: 7.8 (HIGH)
CWE: CWE-120
References: https://git.kernel.org/stable/c/01cdddde39b065074fd48f[PII_REDACTED]3cbf5b7d; https://git.kernel.org/stable/c/73b078e3314d4854fd8286f3ba65c860ddd3a3dd; https://git.kernel.org/stable/c/7b222d6cb87077faf56a687a72af1951cf78c8a9
CVE: CVE-2024-49997
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: lantiq_etop: fix memory disclosure

When applying padding, the buffer is not zeroed, which results in memory
disclosure. The mentioned data is observed on the wire. This patch uses
skb_put_padto() to pad Ethernet frames properly. The mentioned function
zeroes the expanded buffer.

In case the packet cannot be padded it is silently dropped. Statistics
are also not incremented. This driver does not support statistics in the
old 32-bit format or the new 64-bit format. These will be added in the
future. In its current form, the patch should be easily backported to
stable versions.

Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets
in hardware, so software padding must be applied.
CVSS Score: 7.5 (HIGH)
CWE: CWE-212
References: https://git.kernel.org/stable/c/1097bf16501ed5e35358d848b0a94ad2830b0f65; https://git.kernel.org/stable/c/185df159843d30fb71f821e7ea4368c2a3bfcd36; https://git.kernel.org/stable/c/2bf4c101d7c99483b8b15a0c8f881e3f399f7e18
CVE: CVE-2024-49999
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

afs: Fix the setting of the server responding flag

In afs_wait_for_operation(), we set transcribe the call responded flag to
the server record that we used after doing the fileserver iteration loop -
but it's possible to exit the loop having had a response from the server
that we've discarded (e.g. it returned an abort or we started receiving
data, but the call didn't complete).

This means that op->server might be NULL, but we don't check that before
attempting to set the server flag.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3d51ab44123f35dd1d646d99a15ebef10f55e263; https://git.kernel.org/stable/c/97c953572d98080c5f[PII_REDACTED]bb688041747a; https://git.kernel.org/stable/c/ff98751bae40faed1ba9c6a7287e84430f7dec64
CVE: CVE-2024-50000
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()

In mlx5e_tir_builder_alloc() kvzalloc() may return NULL
which is dereferenced on the next line in a reference
to the modify field.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0168ab6fbd9e50d20b97486168b604b2ab28a2ca; https://git.kernel.org/stable/c/1bcc86cc721bea68980098f51f102aa2c2b9d932; https://git.kernel.org/stable/c/4655456a64a0f936098c8432bac64e7176bd2aff
CVE: CVE-2024-50001
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix error path in multi-packet WQE transmit

Remove the erroneous unmap in case no DMA mapping was established

The multi-packet WQE transmit code attempts to obtain a DMA mapping for
the skb. This could fail, e.g. under memory pressure, when the IOMMU
driver just can't allocate more memory for page tables. While the code
tries to handle this in the path below the err_unmap label it erroneously
unmaps one entry from the sq's FIFO list of active mappings. Since the
current map attempt failed this unmap is removing some random DMA mapping
that might still be required. If the PCI function now presents that IOVA,
the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI
function in error state.

The erroneous behavior was seen in a stress-test environment that created
memory pressure.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-755
References: https://git.kernel.org/stable/c/26fad69b34fcba80d5c7d9e651f628e6ac927754; https://git.kernel.org/stable/c/2bcae12c795f32ddfbf8c80d1b5f1d3286341c32; https://git.kernel.org/stable/c/8bb8c12fb5e2b1f03d603d493c92941676f109b5
CVE: CVE-2024-50002
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

static_call: Handle module init failure correctly in static_call_del_module()

Module insertion invokes static_call_add_module() to initialize the static
calls in a module. static_call_add_module() invokes __static_call_init(),
which allocates a struct static_call_mod to either encapsulate the built-in
static call sites of the associated key into it so further modules can be
added or to append the module to the module chain.

If that allocation fails the function returns with an error code and the
module core invokes static_call_del_module() to clean up eventually added
static_call_mod entries.

This works correctly, when all keys used by the module were converted over
to a module chain before the failure. If not then static_call_del_module()
causes a #GP as it blindly assumes that key::mods points to a valid struct
static_call_mod.

The problem is that key::mods is not a individual struct member of struct
static_call_key, it's part of a union to save space:

        union {
                /* bit 0: 0 = mods, 1 = sites */
                unsigned long type;
                struct static_call_mod *mods;
                struct static_call_site *sites;
	};

key::sites is a pointer to the list of built-in usage sites of the static
call. The type of the pointer is differentiated by bit 0. A mods pointer
has the bit clear, the sites pointer has the bit set.

As static_call_del_module() blidly assumes that the pointer is a valid
static_call_mod type, it fails to check for this failure case and
dereferences the pointer to the list of built-in call sites, which is
obviously bogus.

Cure it by checking whether the key has a sites or a mods pointer.

If it's a sites pointer then the key is not to be touched. As the sites are
walked in the same order as in __static_call_init() the site walk can be
terminated because all subsequent sites have not been touched by the init
code due to the error exit.

If it was converted before the allocation fail, then the inner loop which
searches for a module match will find nothing.

A fail in the second allocation in __static_call_init() is harmless and
does not require special treatment. The first allocation succeeded and
converted the key to a module chain. That first entry has mod::mod == NULL
and mod::next == NULL, so the inner loop of static_call_del_module() will
neither find a module match nor a module chain. The next site in the walk
was either already converted, but can't match the module, or it will exit
the outer loop because it has a static_call_site pointer and not a
static_call_mod pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-755
References: https://git.kernel.org/stable/c/2b494471797bff3d257e99dc0a7abb0c5ff3b4cd; https://git.kernel.org/stable/c/4b30051c4864234ec57290c3d142db7c88f10d8a; https://git.kernel.org/stable/c/9c48c2b53191bf991361998f5bb97b8f2fc5a89c