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

udf: Fix NULL pointer dereference in udf_symlink function

In function udf_symlink, epos.bh is assigned with the value returned
by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c
and returns the value of sb_getblk function that could be NULL.
Then, epos.bh is used without any check, causing a possible
NULL pointer dereference when sb_getblk fails.

This fix adds a check to validate the value of epos.bh.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/21bf1414580c36ffc8d8de043beb3508cf812238; https://git.kernel.org/stable/c/2f3d9ddd32a28803baa547e6274983b67d5e287c; https://git.kernel.org/stable/c/3638705ecd5ad2785e996f820121c0ad15ce64b5
CVE: CVE-2021-47354
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/sched: Avoid data corruptions

Wait for all dependencies of a job  to complete before
killing it to avoid data corruptions.
CVSS Score: 9.1 (CRITICAL)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0687411e2a8858262de2fc4a1d576016fd77292e; https://git.kernel.org/stable/c/0b10ab80695d61422337ede6ff496552d8ace99d; https://git.kernel.org/stable/c/50d7e03ad487cc45fc85164a299b945a41756ac0
CVE: CVE-2021-47355
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

atm: nicstar: Fix possible use-after-free in nicstar_cleanup()

This module'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/2f958b6f6ba0854b39be748d21dfe71e0fe6580f; https://git.kernel.org/stable/c/34e7434ba4e97f4b85c1423a59b2922ba7dff2ea; https://git.kernel.org/stable/c/4e2a0848ea2cab0716d46f85a8ccd5fa9a493e51
CVE: CVE-2021-47356
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mISDN: fix possible use-after-free in HFC_cleanup()

This module'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.7 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/009fc857c5f6fda81f2f7dd851b2d54193a8e733; https://git.kernel.org/stable/c/3ecd228c636ee17c[PII_REDACTED]fa07242a93cb0; https://git.kernel.org/stable/c/49331c07ef0f8fdfa42b30ba6a83a657b29d7fbe
CVE: CVE-2021-47357
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

atm: iphase: fix possible use-after-free in ia_module_exit()

This module'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/1c72e6ab66b9598cac741ed397438a52065a8f1f; https://git.kernel.org/stable/c/89ce0b0747f319eb70f85bc820dcc43cebbd5417; https://git.kernel.org/stable/c/9e[PII_REDACTED]5334ca93c6c3ccb[PII_REDACTED]79
CVE: CVE-2021-47358
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: greybus: uart: fix tty use after free

User space can hold a tty open indefinitely and tty drivers must not
release the underlying structures until the last user is gone.

Switch to using the tty-port reference counter to manage the life time
of the greybus tty state to avoid use after free after a disconnect.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/4dc56951a8d9d61d364d346c61a5f1d70b4f5e14; https://git.kernel.org/stable/c/64062fcaca8872f063ec9da011e7bf30470be33f; https://git.kernel.org/stable/c/92b67aaafb7c449db9f0c3dcabc0ff967cb3a42d
CVE: CVE-2021-47359
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix soft lockup during fsstress

Below traces are observed during fsstress and system got hung.
[  130.698396] watchdog: BUG: soft lockup - CPU#6 stuck for 26s!
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/71826b068884050d5fdd37fda857ba1539c513d3; https://git.kernel.org/stable/c/9f6c7aff21f81ae8856da1f63847d1362d523409; https://git.kernel.org/stable/c/71826b068884050d5fdd37fda857ba1539c513d3
CVE: CVE-2021-47360
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

binder: make sure fd closes complete

During BC_FREE_BUFFER processing, the BINDER_TYPE_FDA object
cleanup may close 1 or more fds. The close operations are
completed using the task work mechanism -- which means the thread
needs to return to userspace or the file object may never be
dereferenced -- which can lead to hung processes.

Force the binder thread back to userspace if an fd is closed during
BC_FREE_BUFFER handling.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-252
References: https://git.kernel.org/stable/c/5fdb55c1ac9585eb23bb2541d[PII_REDACTED]e103d; https://git.kernel.org/stable/c/aa2c274c279ff365a06a4cba263f[PII_REDACTED]6e; https://git.kernel.org/stable/c/b95483d8d94b41fa31a84c1d86710b7907a37621
CVE: CVE-2021-47361
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mcb: fix error handling in mcb_alloc_bus()

There are two bugs:
1) If ida_simple_get() fails then this code calls put_device(carrier)
   but we haven't yet called get_device(carrier) and probably that
   leads to a use after free.
2) After device_initialize() then we need to use put_device() to
   release the bus.  This will free the internal resources tied to the
   device and call mcb_free_bus() which will free the rest.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/115b07d9f47e3996430b8f2007edd9768e1f807f; https://git.kernel.org/stable/c/25a[PII_REDACTED]de4abc889910f744e952cb6dbae; https://git.kernel.org/stable/c/66f74ba9be9daf9c47fface6af3677f602774f6b
CVE: CVE-2021-47362
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Update intermediate power state for SI

Update the current state as boot state during dpm initialization.
During the subsequent initialization, set_power_state gets called to
transition to the final power state. set_power_state refers to values
from the current state and without current state populated, it could
result in NULL pointer dereference.

For ex: on platforms where PCI speed change is supported through ACPI
ATCS method, the link speed of current state needs to be queried before
deciding on changing to final power state's link speed. The logic to query
ATCS-support was broken on certain platforms. The issue became visible
when broken ATCS-support logic got fixed with commit
f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)").

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/06a18e64256f7aecb5a27df02faa3568fcd3c105; https://git.kernel.org/stable/c/68d4fbe6220cd1f3d07cab0a4901e62f8c12cc68; https://git.kernel.org/stable/c/ab39d3cef526ba09c4c6923b4cd7e6ec1c5d4faa
CVE: CVE-2021-47363
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

nexthop: Fix division by zero while replacing a resilient group

The resilient nexthop group torture tests in fib_nexthop.sh exposed a
possible division by zero while replacing a resilient group [1]. The
division by zero occurs when the data path sees a resilient nexthop
group with zero buckets.

The tests replace a resilient nexthop group in a loop while traffic is
forwarded through it. The tests do not specify the number of buckets
while performing the replacement, resulting in the kernel allocating a
stub resilient table (i.e, 'struct nh_res_table') with zero buckets.

This table should never be visible to the data path, but the old nexthop
group (i.e., 'oldg') might still be used by the data path when the stub
table is assigned to it.

Fix this by only assigning the stub table to the old nexthop group after
making sure the group is no longer used by the data path.

Tested with fib_nexthops.sh:

Tests passed: 222
Tests failed:   0

[1]
 divide error: 0000 [#1] PREEMPT SMP KASAN
 CPU: 0 PID: 1850 Comm: ping Not tainted 5.14.0-custom-10271-ga86eb53057fe #1107
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
 RIP: 0010:nexthop_select_path+0x2d2/0x1a80
[...]
 Call Trace:
  fib_select_multipath+0x79b/0x1530
  fib_select_path+0x8fb/0x1c10
  ip_route_output_key_hash_rcu+0x1198/0x2da0
  ip_route_output_key_hash+0x190/0x340
  ip_route_output_flow+0x21/0x120
  raw_sendmsg+0x91d/0x2e10
  inet_sendmsg+0x9e/0xe0
  __sys_sendto+0x23d/0x360
  __x64_sys_sendto+0xe1/0x1b0
  do_syscall_64+0x35/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/563f23b002534176f49524b5ca0e1d94d8906c40; https://git.kernel.org/stable/c/e9d32ec26e7f01d1af13bdc687f586362546aa25; https://git.kernel.org/stable/c/563f23b002534176f49524b5ca0e1d94d8906c40
CVE: CVE-2021-47364
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: Fix memory leak in compat_insnlist()

`compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST`
ioctl (whenwhen `CONFIG_COMPAT` is enabled).  It allocates memory to
temporarily hold an array of `struct comedi_insn` converted from the
32-bit version in user space.  This memory is only being freed if there
is a fault while filling the array, otherwise it is leaked.

Add a call to `kfree()` to fix the leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/8d6a21e4cd6a319b0662cbe4ad6199e276ac776a; https://git.kernel.org/stable/c/bb509a6ffed2c8b0950f637ab5779aa818ed1596; https://git.kernel.org/stable/c/f217b6c1e28ed0b353634ce4d92a155b80bd1671
CVE: CVE-2021-47365
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

afs: Fix page leak

There's a loop in afs_extend_writeback() that adds extra pages to a write
we want to make to improve the efficiency of the writeback by making it
larger.  This loop stops, however, if we hit a page we can't write back
from immediately, but it doesn't get rid of the page ref we speculatively
acquired.

This was caused by the removal of the cleanup loop when the code switched
from using find_get_pages_contig() to xarray scanning as the latter only
gets a single page at a time, not a batch.

Fix this by putting the page on a ref on an early break from the loop.
Unfortunately, we can't just add that page to the pagevec we're employing
as we'll go through that and add those pages to the RPC call.

This was found by the generic/074 test.  It leaks ~4GiB of RAM each time it
is run - which can be observed with "top".
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-459
References: https://git.kernel.org/stable/c/581b2027af0018944ba301d68e7af45c6d1128b5; https://git.kernel.org/stable/c/d130b5fdd42254d92948d[PII_REDACTED]6140c927e; https://git.kernel.org/stable/c/581b2027af0018944ba301d68e7af45c6d1128b5
CVE: CVE-2021-47366
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server

AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and
Linux's afs client switches between them when talking to a non-YFS server
if the read size, the file position or the sum of the two have the upper 32
bits set of the 64-bit value.

This is a problem, however, since the file position and length fields of
FS.FetchData are *signed* 32-bit values.

Fix this by capturing the capability bits obtained from the fileserver when
it's sent an FS.GetCapabilities RPC, rather than just discarding them, and
then picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be
used to decide whether to use FS.FetchData or FS.FetchData64 - and also
FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to
switch on the parameter values.

This capabilities flag could also be used to limit the maximum size of the
file, but all servers must be checked for that.

Note that the issue does not exist with FS.StoreData - that uses *unsigned*
32-bit values.  It's also not a problem with Auristor servers as its
YFS.FetchData64 op uses unsigned 64-bit values.

This can be tested by cloning a git repo through an OpenAFS client to an
OpenAFS server and then doing "git status" on it from a Linux afs
client[1].  Provided the clone has a pack file that's in the 2G-4G range,
the git status will show errors like:

	error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
	error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index

This can be observed in the server's FileLog with something like the
following appearing:

Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid =[PII_REDACTED][PII_REDACTED]114, Host 192.168.11.201:7001, Id 1001
Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos[PII_REDACTED][PII_REDACTED], Len 3154
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size[PII_REDACTED]
...
Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5

Note the file position of[PII_REDACTED][PII_REDACTED].  This is the requested file
position sign-extended.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/b537a3c[PII_REDACTED]5af475dcc6ef212fcf29db8; https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97; https://git.kernel.org/stable/c/b537a3c[PII_REDACTED]5af475dcc6ef212fcf29db8
CVE: CVE-2021-47367
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-net: fix pages leaking when building skb in big mode

We try to use build_skb() if we had sufficient tailroom. But we forget
to release the unused pages chained via private in big mode which will
leak pages. Fixing this by release the pages after building the skb in
big mode.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-119
References: https://git.kernel.org/stable/c/afd92d82c9d715fb[PII_REDACTED]5acad81573591a; https://git.kernel.org/stable/c/f020bb63b5d2e5576acadd10e158fe3b04af67ba; https://git.kernel.org/stable/c/afd92d82c9d715fb[PII_REDACTED]5acad81573591a
CVE: CVE-2021-47368
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

enetc: Fix illegal access when reading affinity_hint

irq_set_affinity_hit() stores a reference to the cpumask_t
parameter in the irq descriptor, and that reference can be
accessed later from irq_affinity_hint_proc_show(). Since
the cpu_mask parameter passed to irq_set_affinity_hit() has
only temporary storage (it's on the stack memory), later
accesses to it are illegal. Thus reads from the corresponding
procfs affinity_hint file can result in paging request oops.

The issue is fixed by the get_cpu_mask() helper, which provides
a permanent storage for the cpumask_t parameter.
CVSS Score: 8.1 (HIGH)
CWE: CWE-400
References: https://git.kernel.org/stable/c/4c4c3052911b577920353a7646e4883d5da40c28; https://git.kernel.org/stable/c/6c3f1b741c6c2914ea120e3a5790d3e900152f7b; https://git.kernel.org/stable/c/6f329d9da2a5ae032fcde800a99b118124ed5270
CVE: CVE-2021-47369
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/qeth: fix NULL deref in qeth_clear_working_pool_list()

When qeth_set_online() calls qeth_clear_working_pool_list() to roll
back after an error exit from qeth_hardsetup_card(), we are at risk of
accessing card->qdio.in_q before it was allocated by
qeth_alloc_qdio_queues() via qeth_mpc_initialize().

qeth_clear_working_pool_list() then dereferences NULL, and by writing to
queue->bufs[i].pool_entry scribbles all over the CPU's lowcore.
Resulting in a crash when those lowcore areas are used next (eg. on
the next machine-check interrupt).

Such a scenario would typically happen when the device is first set
online and its queues aren't allocated yet. An early IO error or certain
misconfigs (eg. mismatched transport mode, bad portno) then cause us to
error out from qeth_hardsetup_card() with card->qdio.in_q still being
NULL.

Fix it by checking the pointer for NULL before accessing it.

Note that we also have (rare) paths inside qeth_mpc_initialize() where
a configuration change can cause us to free the existing queues,
expecting that subsequent code will allocate them again. If we then
error out before that re-allocation happens, the same bug occurs.

Root-caused-by: Heiko Carstens <hca@linux.ibm.com>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/248f064af222a1f97ee02c84a98013dfbccad386; https://git.kernel.org/stable/c/9b00fb12cdc9d8d1c3ffe82a78e[PII_REDACTED]3fc; https://git.kernel.org/stable/c/db94f89e1dadf693c15c2d60de0c34777cea5779
CVE: CVE-2021-47372
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: macb: fix use after free on rmmod

plat_dev->dev->platform_data is released by platform_device_unregister(),
use of pclk and hclk is a use-after-free. Since device unregister won't
need a clk device we adjust the function call sequence to fix this issue.

[   31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci]
[   31.275563] Freed by task 306:
[   30.276782]  platform_device_release+0x25/0x80
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1da750d1e2140ef43d64d17f301ff6f41b45541e; https://git.kernel.org/stable/c/46670fb832ee80943715df618632ca13c2e96f2b; https://git.kernel.org/stable/c/4ad6f2d23b0f6ac0d3e5f3102a4256d1c86c90f5
CVE: CVE-2021-47373
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v3-its: Fix potential VPE leak on error

In its_vpe_irq_domain_alloc, when its_vpe_init() returns an error,
there is an off-by-one in the number of VPEs to be freed.

Fix it by simply passing the number of VPEs allocated, which is the
index of the loop iterating over the VPEs.

[maz: fixed commit message]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-193
References: https://git.kernel.org/stable/c/280bef512933b2dda01d681d8cbe499b98fc5bdd; https://git.kernel.org/stable/c/42d3711c23781045e7a5cd28536c774b9a66d20b; https://git.kernel.org/stable/c/568662e37f927e3dc3e475f3ff7cf4ab7719c5e7
CVE: CVE-2021-47374
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

dma-debug: prevent an error message from causing runtime problems

For some drivers, that use the DMA API. This error message can be reached
several millions of times per second, causing spam to the kernel's printk
buffer and bringing the CPU usage up to 100% (so, it should be rate
limited). However, since there is at least one driver that is in the
mainline and suffers from the error condition, it is more useful to
err_printk() here instead of just rate limiting the error message (in hopes
that it will make it easier for other drivers that suffer from this issue
to be spotted).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/510e1a724ab1bf38150be2c1acabb303f98d0047; https://git.kernel.org/stable/c/de4afec2d2946c92c62a15ab341c70b287289e6a; https://git.kernel.org/stable/c/510e1a724ab1bf38150be2c1acabb303f98d0047
CVE: CVE-2021-47375
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

blktrace: Fix uaf in blk_trace access after removing by sysfs

There is an use-after-free problem triggered by following process:

      P1(sda)				P2(sdb)
			echo 0 > /sys/block/sdb/trace/enable
			  blk_trace_remove_queue
			    synchronize_rcu
			    blk_trace_free
			      relay_close
rcu_read_lock
__blk_add_trace
  trace_note_tsk
  (Iterate running_trace_list)
			        relay_close_buf
				  relay_destroy_buf
				    kfree(buf)
    trace_note(sdb's bt)
      relay_reserve
        buf->offset <- nullptr deference (use-after-free) !!!
rcu_read_unlock

[  502.714379] BUG: kernel NULL pointer dereference, address:
[PII_REDACTED]
[  502.715260] #PF: supervisor read access in kernel mode
[  502.715903] #PF: error_code(0x0000) - not-present page
[  502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0
[  502.717252] Oops: 0000 [#1] SMP
[  502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360
[  502.732872] Call Trace:
[  502.733193]  __blk_add_trace.cold+0x137/0x1a3
[  502.733734]  blk_add_trace_rq+0x7b/0xd0
[  502.734207]  blk_add_trace_rq_issue+0x54/0xa0
[  502.734755]  blk_mq_start_request+0xde/0x1b0
[  502.735287]  scsi_queue_rq+0x528/0x1140
...
[  502.742704]  sg_new_write.isra.0+0x16e/0x3e0
[  502.747501]  sg_ioctl+0x466/0x1100

Reproduce method:
  ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127])
  ioctl(/dev/sda, BLKTRACESTART)
  ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127])
  ioctl(/dev/sdb, BLKTRACESTART)

  echo 0 > /sys/block/sdb/trace/enable &
  // Add delay(mdelay/msleep) before kernel enters blk_trace_free()

  ioctl$SG_IO(/dev/sda, SG_IO, ...)
  // Enters trace_note_tsk() after blk_trace_free() returned
  // Use mdelay in rcu region rather than msleep(which may schedule out)

Remove blk_trace from running_list before calling blk_trace_free() by
sysfs if blk_trace is at Blktrace_running state.
CVSS Score: 6.2 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3815fe7371d2411ce164281cef40d9fc7b323dee; https://git.kernel.org/stable/c/488da313edf3abea7f7733efe011c96b23740ab5; https://git.kernel.org/stable/c/5afedf670caf30a2b5a52da96eb7eac7dee6a9c9
CVE: CVE-2021-47376
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Add oversize check before call kvcalloc()

Commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls") add the
oversize check. When the allocation is larger than what kmalloc() supports,
the following warning triggered:

WARNING: CPU: 0 PID: 8408 at mm/util.c:597 kvmalloc_node+0x108/0x110 mm/util.c:597
Modules linked in:
CPU: 0 PID: 8408 Comm: syz-executor221 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:kvmalloc_node+0x108/0x110 mm/util.c:597
Call Trace:
 kvmalloc include/linux/mm.h:806 [inline]
 kvmalloc_array include/linux/mm.h:824 [inline]
 kvcalloc include/linux/mm.h:829 [inline]
 check_btf_line kernel/bpf/verifier.c:9925 [inline]
 check_btf_info kernel/bpf/verifier.c:10049 [inline]
 bpf_check+0xd634/0x150d0 kernel/bpf/verifier.c:13759
 bpf_prog_load kernel/bpf/syscall.c:2301 [inline]
 __sys_bpf+0x11181/0x126e0 kernel/bpf/syscall.c:4587
 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
 __x64_sys_bpf+0x78/0x90 kernel/bpf/syscall.c:4689
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0e6491b559704da720f6da09dd0a52c4df44c514; https://git.kernel.org/stable/c/6345a0bee80139ea00a341c4202ebfd1534b5eb0; https://git.kernel.org/stable/c/93937596e0652d50973f9dc944fea1694ac8cdfd