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

kvm: avoid speculation-based attacks from out-of-range memslot accesses

KVM's mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot.  The translation is
performed in __gfn_to_hva_memslot using the following formula:

      hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE

It is expected that gfn falls within the boundaries of the guest's
physical memory.  However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.

__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest's
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva.  If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.

Right now it's not clear if there are any cases in which this is
exploitable.  One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86.  Right
now these are not vulnerable because the hva read goes through get_user(),
which contains an LFENCE speculation barrier.  However, there are
patches in progress for x86 uaccess.h to mask kernel addresses instead of
using LFENCE; once these land, a guest could use speculation to read
from the VMM's ring 3 address space.  Other architectures such as ARM
already use the address masking method, and would be susceptible to
this same kind of data-dependent access gadgets.  Therefore, this patch
proactively protects from these attacks by masking out-of-bounds gfns
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.

Sean Christopherson noted that this patch does not cover
kvm_read_guest_offset_cached.  This however is limited to a few bytes
past the end of the cache, and therefore it is unlikely to be useful in
the context of building a chain of data dependent accesses.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/22b87fb17a28d37331bb9c[PII_REDACTED]b17f6781; https://git.kernel.org/stable/c/3098b86390a6b9ea52657689f08410baf130ceff; https://git.kernel.org/stable/c/361ce3b917aff93123e9e966d8608655c967f438
CVE: CVE-2021-47278
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

bus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove()

This driver's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0b67808ade8893a1b3608ddd74fac7854786c919; https://git.kernel.org/stable/c/c597d5c59c7a6417dba06590f59b922e01188e8d; https://git.kernel.org/stable/c/0b67808ade8893a1b3608ddd74fac7854786c919
CVE: CVE-2021-47279
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2147684be1ebdaf845783139b9bc4eba3fecd9e4; https://git.kernel.org/stable/c/fbf649cd6d64d40c03c5397ecd6b1ae922ba7afc; https://git.kernel.org/stable/c/2147684be1ebdaf845783139b9bc4eba3fecd9e4
CVE: CVE-2021-47280
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: Fix use-after-free read in drm_getunique()

There is a time-of-check-to-time-of-use error in drm_getunique() due
to retrieving file_priv->master prior to locking the device's master
mutex.

An example can be seen in the crash report of the use-after-free error
found by Syzbot:
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803

In the report, the master pointer was used after being freed. This is
because another process had acquired the device's master mutex in
drm_setmaster_ioctl(), then overwrote fpriv->master in
drm_new_set_master(). The old value of fpriv->master was subsequently
freed before the mutex was unlocked.

To fix this, we lock the device's master mutex before retrieving the
pointer from from fpriv->master. This patch passes the Syzbot
reproducer test.
CVSS Score: 7.0 (HIGH)
CWE: CWE-367, CWE-416
References: https://git.kernel.org/stable/c/17dab9326ff263c62dab1dbac4492e2938a049e4; https://git.kernel.org/stable/c/491d52e0078860b33b6c14f0a7ac74ca1b603bd6; https://git.kernel.org/stable/c/7d233ba700ceb593905ea82b42dadb4ec8ef85e9
CVE: CVE-2021-47281
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: seq: Fix race of snd_seq_timer_open()

The timer instance per queue is exclusive, and snd_seq_timer_open()
should have managed the concurrent accesses.  It looks as if it's
checking the already existing timer instance at the beginning, but
it's not right, because there is no protection, hence any later
concurrent call of snd_seq_timer_open() may override the timer
instance easily.  This may result in UAF, as the leftover timer
instance can keep running while the queue itself gets closed, as
spotted by syzkaller recently.

For avoiding the race, add a proper check at the assignment of
tmr->timeri again, and return -EBUSY if it's been already registered.
CVSS Score: 7.0 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/536a7646c00a0f14fee49e5e313109e5da2f6031; https://git.kernel.org/stable/c/83e197a8414c0ba545e7e3916ce05f836f349273; https://git.kernel.org/stable/c/bd7d88b0874f82f7b29d1a53e574cedaf23166ba
CVE: CVE-2021-47282
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: bcm2835: Fix out-of-bounds access with more than 4 slaves

Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for
->prepare_message()") limited the number of slaves to 3 at compile-time.
The limitation was necessitated by a statically-sized array prepare_cs[]
in the driver private data which contains a per-slave register value.

The commit sought to enforce the limitation at run-time by setting the
controller's num_chipselect to 3:  Slaves with a higher chipselect are
rejected by spi_add_device().

However the commit neglected that num_chipselect only limits the number
of *native* chipselects.  If GPIO chipselects are specified in the
device tree for more than 3 slaves, num_chipselect is silently raised by
of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to
the statically-sized array prepare_cs[].

As a bandaid fix which is backportable to stable, raise the number of
allowed slaves to 24 (which "ought to be enough for anybody"), enforce
the limitation on slave ->setup and revert num_chipselect to 3 (which is
the number of native chipselects supported by the controller).
An upcoming for-next commit will allow an arbitrary number of slaves.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/01415ff85a24308059e06ca3e97fd7bf75648690; https://git.kernel.org/stable/c/13817d466eb8713a1ffd254f537402f091d48444; https://git.kernel.org/stable/c/82a8ffba54d31e97582051cb56ba1f988018681e
CVE: CVE-2021-47283
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net:sfc: fix non-freed irq in legacy irq mode

SFC driver can be configured via modparam to work using MSI-X, MSI or
legacy IRQ interrupts. In the last one, the interrupt was not properly
released on module remove.

It was not freed because the flag irqs_hooked was not set during
initialization in the case of using legacy IRQ.

Example of (trimmed) trace during module remove without this fix:

remove_proc_entry: removing non-empty directory 'irq/125', leaking at least '0000:3b:00.1'
WARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170
...trimmed...
Call Trace:
 unregister_irq_proc+0xe3/0x100
 free_desc+0x29/0x70
 irq_free_descs+0x47/0x70
 mp_unmap_irq+0x58/0x60
 acpi_unregister_gsi_ioapic+0x2a/0x40
 acpi_pci_irq_disable+0x78/0xb0
 pci_disable_device+0xd1/0x100
 efx_pci_remove+0xa1/0x1e0 [sfc]
 pci_device_remove+0x38/0xa0
 __device_release_driver+0x177/0x230
 driver_detach+0xcb/0x110
 bus_remove_driver+0x58/0xd0
 pci_unregister_driver+0x2a/0xb0
 efx_exit_module+0x24/0xf40 [sfc]
 __do_sys_delete_module.constprop.0+0x171/0x280
 ? exit_to_user_mode_prepare+0x83/0x1d0
 do_syscall_64+0x3d/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f9f9385800b
...trimmed...
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-772
References: https://git.kernel.org/stable/c/81c4d1d83f88e15b26f4522a35cba6ffd8c5dfdd; https://git.kernel.org/stable/c/8d717c9135a3340ae62d[PII_REDACTED]bfb4112b0c; https://git.kernel.org/stable/c/8f03eeb6e0a0a0b8d617ee0a4bce729e47130036
CVE: CVE-2021-47285
Published: 2024-05-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2021-47286
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

bus: mhi: core: Validate channel ID when processing command completions

MHI reads the channel ID from the event ring element sent by the
device which can be any value between 0 and 255. In order to
prevent any out of bound accesses, add a check against the maximum
number of channels supported by the controller and those channels
not configured yet so as to skip processing of that event ring
element.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/3efec3b4b16fc7af25676a94230a8ab2a3bb867c; https://git.kernel.org/stable/c/546362a9ef2ef40b57c6605f14e88ced507f8dd0; https://git.kernel.org/stable/c/aed4f5b51aba41e2afd7cfda20a0571a6a67dfe9
CVE: CVE-2021-47287
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

driver core: auxiliary bus: Fix memory leak when driver_register() fail

If driver_register() returns with error we need to free the memory
allocated for auxdrv->driver.name before returning from
__auxiliary_driver_register()
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4afa0c22eed33cfe0c590742387f0d16f32412f3; https://git.kernel.org/stable/c/ce5b3de58fc21303722df46551f7eb9a91afb409; https://git.kernel.org/stable/c/4afa0c22eed33cfe0c590742387f0d16f32412f3
CVE: CVE-2021-47288
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()

Fix an 11-year old bug in ngene_command_config_free_buf() while
addressing the following warnings caught with -Warray-bounds:

arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]

The problem is that the original code is trying to copy 6 bytes of
data into a one-byte size member _config_ of the wrong structue
FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a
legitimate compiler warning because memcpy() overruns the length
of &com.cmd.ConfigureBuffers.config. It seems that the right
structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains
6 more members apart from the header _hdr_. Also, the name of
the function ngene_command_config_free_buf() suggests that the actual
intention is to ConfigureFreeBuffers, instead of ConfigureBuffers
(which takes place in the function ngene_command_config_buf(), above).

Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS
into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as
the destination address, instead of &com.cmd.ConfigureBuffers.config,
when calling memcpy().

This also helps with the ongoing efforts to globally enable
-Warray-bounds and get us closer to being able to tighten the
FORTIFY_SOURCE routines on memcpy().
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/4487b968e5eacd02c493303dc2b61150bb7fe4b2; https://git.kernel.org/stable/c/8d4abca95ecc82fc8c41912fa0085281f19cc29f; https://git.kernel.org/stable/c/b9a178f189bb6d75293573e181928735f5e3e070
CVE: CVE-2021-47289
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: fix NULL pointer dereference

Commit 71f642833284 ("ACPI: utils: Fix reference counting in
for_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointer
that was possibly NULL.  That fails miserably, because that helper
inline function is not set up to handle that case.

Just make acpi_dev_put() silently accept a NULL pointer, rather than
calling down to put_device() with an invalid offset off that NULL
pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/38f54217b423c0101d03a00feec6fb8ec608b12e; https://git.kernel.org/stable/c/cae3fa3d8165761f3000f523b11cfa1cd35206bc; https://git.kernel.org/stable/c/ccf23a0888077a25a0793a746c3941db2a7562e4
CVE: CVE-2021-47290
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: target: Fix NULL dereference on XCOPY completion

CPU affinity control added with commit 39ae3edda325 ("scsi: target: core:
Make completion affinity configurable") makes target_complete_cmd() queue
work on a CPU based on se_tpg->se_tpg_wwn->cmd_compl_affinity state.

LIO's EXTENDED COPY worker is a special case in that read/write cmds are
dispatched using the global xcopy_pt_tpg, which carries a NULL se_tpg_wwn
pointer following initialization in target_xcopy_setup_pt().

The NULL xcopy_pt_tpg->se_tpg_wwn pointer is dereferenced on completion of
any EXTENDED COPY initiated read/write cmds. E.g using the libiscsi
SCSI.ExtendedCopy.Simple test:

  BUG: kernel NULL pointer dereference, address:[PII_REDACTED]0001a8
  RIP: 0010:target_complete_cmd+0x9d/0x130 [target_core_mod]
  Call Trace:
   fd_execute_rw+0x148/0x42a [target_core_file]
   ? __dynamic_pr_debug+0xa7/0xe0
   ? target_check_reservation+0x5b/0x940 [target_core_mod]
   __target_execute_cmd+0x1e/0x90 [target_core_mod]
   transport_generic_new_cmd+0x17c/0x330 [target_core_mod]
   target_xcopy_issue_pt_cmd+0x9/0x60 [target_core_mod]
   target_xcopy_read_source.isra.7+0x10b/0x1b0 [target_core_mod]
   ? target_check_fua+0x40/0x40 [target_core_mod]
   ? transport_complete_task_attr+0x130/0x130 [target_core_mod]
   target_xcopy_do_work+0x61f/0xc00 [target_core_mod]

This fix makes target_complete_cmd() queue work on se_cmd->cpuid if
se_tpg_wwn is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/a47fa41381a09e5997afd762664db4f5f6657e03; https://git.kernel.org/stable/c/e7732c5a19a15a62b0b23fd683a639b0483e1f40; https://git.kernel.org/stable/c/a47fa41381a09e5997afd762664db4f5f6657e03
CVE: CVE-2021-47291
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions

While running the self-tests on a KASAN enabled kernel, I observed a
slab-out-of-bounds splat very similar to the one reported in
commit 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in
 fib6_nh_flush_exceptions").

We additionally need to take care of fib6_metrics initialization
failure when the caller provides an nh.

The fix is similar, explicitly free the route instead of calling
fib6_info_release on a half-initialized object.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/115784bcccf135c3a[PII_REDACTED]413d76f16aae0; https://git.kernel.org/stable/c/[PII_REDACTED]25c5be044db4d826aaf304ea3d14c6; https://git.kernel.org/stable/c/8fb4792f091e608a0a1d353dfdf07ef55a719db5
CVE: CVE-2021-47292
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring: fix memleak in io_init_wq_offload()

I got memory leak report when doing fuzz test:

BUG: memory leak
unreferenced object 0xffff888107310a80 (size 96):
comm "syz-executor.6", pid 4610, jiffies[PII_REDACTED] (age 20.135s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
backtrace:
[<[PII_REDACTED]74933b>] kmalloc include/linux/slab.h:591 [inline]
[<[PII_REDACTED]74933b>] kzalloc include/linux/slab.h:721 [inline]
[<[PII_REDACTED]74933b>] io_init_wq_offload fs/io_uring.c:7920 [inline]
[<[PII_REDACTED]74933b>] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955
[<[PII_REDACTED]d0800d>] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016
[<[PII_REDACTED]82e78c>] io_uring_add_tctx_node fs/io_uring.c:9052 [inline]
[<[PII_REDACTED]82e78c>] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline]
[<[PII_REDACTED]82e78c>] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline]
[<[PII_REDACTED]82e78c>] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301
[<00000000b875f18f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<00000000b875f18f>] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
[<000000006b0a8484>] entry_SYSCALL_64_after_hwframe+0x44/0xae

CPU0                          CPU1
io_uring_enter                io_uring_enter
io_uring_add_tctx_node        io_uring_add_tctx_node
__io_uring_add_tctx_node      __io_uring_add_tctx_node
io_uring_alloc_task_context   io_uring_alloc_task_context
io_init_wq_offload            io_init_wq_offload
hash = kzalloc                hash = kzalloc
ctx->hash_map = hash          ctx->hash_map = hash <- one of the hash is leaked

When calling io_uring_enter() in parallel, the 'hash_map' will be leaked,
add uring_lock to protect 'hash_map'.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/362a9e65289284f36403058eea2462d0330c1f24; https://git.kernel.org/stable/c/502731a03f27cba1513fbbff77e508185ffce5bb; https://git.kernel.org/stable/c/362a9e65289284f36403058eea2462d0330c1f24
CVE: CVE-2021-47293
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_skbmod: Skip non-Ethernet packets

Currently tcf_skbmod_act() assumes that packets use Ethernet as their L2
protocol, which is not always the case.  As an example, for CAN devices:

	$ ip link add dev vcan0 type vcan
	$ ip link set up vcan0
	$ tc qdisc add dev vcan0 root handle 1: htb
	$ tc filter add dev vcan0 parent 1: protocol ip prio 10 \
		matchall action skbmod swap mac

Doing the above silently corrupts all the packets.  Do not perform skbmod
actions for non-Ethernet packets.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/071729150be9e1d1b851b70efb6d91ee9269d57b; https://git.kernel.org/stable/c/34f1e1f657fae2891b485a3b2b95fe4d2aef9f0d; https://git.kernel.org/stable/c/727d6a8b7ef3d25080fad228b2c4a1d4da5999c6
CVE: CVE-2021-47294
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

netrom: Decrease sock refcount when sock timers expire

Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
del_timer() by sk_stop_timer().

Function sk_reset_timer() will increase the refcount of sock if it is
called on an inactive timer, hence, in case the timer expires, we need to
decrease the refcount ourselves in the handler, otherwise, the sock
refcount will be unbalanced and the sock will never be freed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-672
References: https://git.kernel.org/stable/c/25df44e90ff5959b5c24ad361b648504a7e39ef3; https://git.kernel.org/stable/c/48866fd5c361ea417ed24b43fc2a7dc2f5b060ef; https://git.kernel.org/stable/c/517a16b1a88bdb6b530f48d5d153478b2552d9a8
CVE: CVE-2021-47295
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: sched: fix memory leak in tcindex_partial_destroy_work

Syzbot reported memory leak in tcindex_set_parms(). The problem was in
non-freed perfect hash in tcindex_partial_destroy_work().

In tcindex_set_parms() new tcindex_data is allocated and some fields from
old one are copied to new one, but not the perfect hash. Since
tcindex_partial_destroy_work() is the destroy function for old
tcindex_data, we need to free perfect hash to avoid memory leak.
CVSS Score: 7.5 (HIGH)
CWE: CWE-400
References: https://git.kernel.org/stable/c/01d0d2b8b4e3cf2110baba9371c0c3d04ad5c77b; https://git.kernel.org/stable/c/18c3fa7a7fdbb4d21dafc8a7710ae2c1680930f6; https://git.kernel.org/stable/c/372ae77cf11d11fb118cbe2d37def9dd5f826abd
CVE: CVE-2021-47296
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak

vcpu_put is not called if the user copy fails. This can result in preempt
notifier corruption and crashes, among other issues.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/9bafc34dc4ad0cef18727c557f21ed3c3304df50; https://git.kernel.org/stable/c/a4a488915feaad38345cc01b80d52e8200ff5209; https://git.kernel.org/stable/c/bc4188a2f56e821ea057aca6bf444e138d06c252
CVE: CVE-2021-47297
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: fix uninit-value in caif_seqpkt_sendmsg

When nr_segs equal to zero in iovec_from_user, the object
msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg
which is defined in ___sys_sendmsg. So we cann't just judge
msg->msg_iter.iov->base directlly. We can use nr_segs to judge
msg in caif_seqpkt_sendmsg whether has data buffers.

=====================================================
BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x220 lib/dump_stack.c:118
 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
 caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
 sock_sendmsg_nosec net/socket.c:652 [inline]
 sock_sendmsg net/socket.c:672 [inline]
 ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343
 ___sys_sendmsg net/socket.c:2397 [inline]
 __sys_sendmmsg+0x808/0xc90 net/socket.c:2480
 __compat_sys_sendmmsg net/compat.c:656 [inline]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/1582a02fecffcee306663035a295e28e1c4aaaff; https://git.kernel.org/stable/c/452c3ed7bf63721b07bc2238ed1261bb26027e85; https://git.kernel.org/stable/c/5c6d8e2f7187b8e45a18c27acb7a3885f03ee3db
CVE: CVE-2021-47298
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix potential memory leak on unlikely error case

If skb_linearize is needed and fails we could leak a msg on the error
handling. To fix ensure we kfree the msg block before returning error.
Found during code review.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/6c508a1c6c62793dc6e6872cad4b200097bab7c9; https://git.kernel.org/stable/c/715f378f42909c401ec043f5150c4fdf57fb8889; https://git.kernel.org/stable/c/7e6b27a69167f97c56b5437871d29e9722c3e470