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

mm/page_owner: use strscpy() instead of strlcpy()

current->comm[] is not a string (no guarantee for a zero byte in it).

strlcpy(s1, s2, l) is calling strlen(s2), potentially
causing out-of-bound access, as reported by syzbot:

detected buffer overflow in __fortify_strlen
------------[ cut here ]------------
kernel BUG at lib/string_helpers.c:980!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 4087 Comm: dhcpcd-run-hooks Not tainted 5.18.0-rc3-syzkaller-01537-g20b87e7c29df #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:fortify_panic+0x18/0x1a lib/string_helpers.c:980
Code: 8c e8 c5 ba e1 fa e9 23 0f bf fa e8 0b 5d 8c f8 eb db 55 48 89 fd e8 e0 49 40 f8 48 89 ee 48 c7 c7 80 f5 26 8a e8 99 09 f1 ff <0f> 0b e8 ca 49 40 f8 48 8b 54 24 18 4c 89 f1 48 c7 c7 00 00 27 8a
RSP: 0018:ffffc900000074a8 EFLAGS: 00010286

RAX:[PII_REDACTED]00002c RBX: ffff88801226b728 RCX: [PII_REDACTED]
RDX: ffff8880198e0000 RSI: ffffffff81600458 RDI: fffff52000000e87
RBP: ffffffff89da2aa0 R08:[PII_REDACTED]00002c R09: [PII_REDACTED]
R10: ffffffff815fae2e R11: [PII_REDACTED] R12: ffff88801226b700
R13: ffff8880198e0830 R14: [PII_REDACTED] R15: [PII_REDACTED]
FS:  [PII_REDACTED](0000) GS:ffff8880b9c00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f5876ad6ff8 CR3: 000000001a48c000 CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <IRQ>
 __fortify_strlen include/linux/fortify-string.h:128 [inline]
 strlcpy include/linux/fortify-string.h:143 [inline]
 __set_page_owner_handle+0x2b1/0x3e0 mm/page_owner.c:171
 __set_page_owner+0x3e/0x50 mm/page_owner.c:190
 prep_new_page mm/page_alloc.c:2441 [inline]
 get_page_from_freelist+0xba2/0x3e00 mm/page_alloc.c:4182
 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5408
 alloc_pages+0x1aa/0x310 mm/mempolicy.c:2272
 alloc_slab_page mm/slub.c:1799 [inline]
 allocate_slab+0x26c/0x3c0 mm/slub.c:1944
 new_slab mm/slub.c:2004 [inline]
 ___slab_alloc+0x8df/0xf20 mm/slub.c:3005
 __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3092
 slab_alloc_node mm/slub.c:3183 [inline]
 slab_alloc mm/slub.c:3225 [inline]
 __kmem_cache_alloc_lru mm/slub.c:3232 [inline]
 kmem_cache_alloc+0x360/0x3b0 mm/slub.c:3242
 dst_alloc+0x146/0x1f0 net/core/dst.c:92
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/5cd9900a1ac8b0a4ff3cd97d4d77b7711be435bf; https://git.kernel.org/stable/c/cd8c1fd8cdd14158f2d8bea2d1bfe8015dccfa3a
CVE: CVE-2022-49402
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ftrace: Clean up hash direct_functions on register failures

We see the following GPF when register_ftrace_direct fails:

[ ] general protection fault, probably for non-canonical address \
  0x[PII_REDACTED]00010: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
[...]
[ ] RIP: 0010:ftrace_find_rec_direct+0x53/0x70
[ ] Code: 48 c1 e0 03 48 03 42 08 48 8b 10 31 c0 48 85 d2 74 [...]
[ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206
[ ] RAX: [PII_REDACTED] RBX: ffffffff813e0df0 RCX:[PII_REDACTED]00003b
[ ] RDX: [PII_REDACTED] RSI:[PII_REDACTED]00000c RDI: ffffffff813e0df0
[ ] RBP: ffffffffa00a3000 R08: ffffffff81180ce0 R09: [PII_REDACTED]
[ ] R10: ffffc9000138bc18 R11: [PII_REDACTED] R12: ffffffff813e0df0
[ ] R13: ffffffff813e0df0 R14: ffff888171b56400 R15: [PII_REDACTED]
[ ] FS:  00007fa9420c7780(0000) GS:ffff888ff6a00000(0000) knlGS:000000000
[ ] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[ ] CR2:[PII_REDACTED]70d000 CR3:[PII_REDACTED]d50003 CR4:[PII_REDACTED]370ee0
[ ] DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
[ ] DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
[ ] Call Trace:
[ ]  <TASK>
[ ]  register_ftrace_direct+0x54/0x290
[ ]  ? render_sigset_t+0xa0/0xa0
[ ]  bpf_trampoline_update+0x3f5/0x4a0
[ ]  ? 0xffffffffa00a3000
[ ]  bpf_trampoline_link_prog+0xa9/0x140
[ ]  bpf_tracing_prog_attach+0x1dc/0x450
[ ]  bpf_raw_tracepoint_open+0x9a/0x1e0
[ ]  ? find_held_lock+0x2d/0x90
[ ]  ? lock_release+0x150/0x430
[ ]  __sys_bpf+0xbd6/0x2700
[ ]  ? lock_is_held_type+0xd8/0x130
[ ]  __x64_sys_bpf+0x1c/0x20
[ ]  do_syscall_64+0x3a/0x80
[ ]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ ] RIP: 0033:0x7fa9421defa9
[ ] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 9 f8 [...]
[ ] RSP: 002b:00007ffed743bd78 EFLAGS: 00000246 ORIG_RAX: [PII_REDACTED]
[ ] RAX: ffffffffffffffda RBX:[PII_REDACTED]9d2480 RCX: 00007fa9421defa9
[ ] RDX: [PII_REDACTED] RSI: 00007ffed743bd80 RDI: [PII_REDACTED]
[ ] RBP: 00007ffed743be00 R08:[PII_REDACTED]bb7270 R09: [PII_REDACTED]
[ ] R10:[PII_REDACTED]9da210 R11: [PII_REDACTED] R12: [PII_REDACTED]
[ ] R13: 00007ffed743c4b0 R14:[PII_REDACTED]9d2480 R15: [PII_REDACTED]
[ ]  </TASK>
[ ] Modules linked in: klp_vm(OK)
[ ] ---[ end trace [PII_REDACTED] ]---

One way to trigger this is:
  1. load a livepatch that patches kernel function xxx;
  2. run bpftrace -e 'kfunc:xxx {}', this will fail (expected for now);
  3. repeat #2 => gpf.

This is because the entry is added to direct_functions, but not removed.
Fix this by remove the entry from direct_functions when
register_ftrace_direct fails.

Also remove the last trailing space from ftrace.c, so we don't have to
worry about it anymore.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7d54c15cb89a29a5f59e5ffc9ee62e6591769ef1; https://git.kernel.org/stable/c/805e87af946d8d[PII_REDACTED]e64d143ff37a441b; https://git.kernel.org/stable/c/82c888e51c2176a06f8b4541cf748ee81aac6e7e
CVE: CVE-2022-49403
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

lib/string_helpers: fix not adding strarray to device's resource list

Add allocated strarray to device's resource list. This is a must to
automatically release strarray when the device disappears.

Without this fix we have a memory leak in the few drivers which use
devm_kasprintf_strarray().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/a152eb42fcecfe41239c3c6695342f3a128593e7; https://git.kernel.org/stable/c/bf29edab0c9ff3d2633b8306a67d04c357e2a385; https://git.kernel.org/stable/c/cd290a9839cee2f[PII_REDACTED]e707bd373c8f6f1
CVE: CVE-2022-49404
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/hfi1: Fix potential integer multiplication overflow errors

When multiplying of different types, an overflow is possible even when
storing the result in a larger type. This is because the conversion is
done after the multiplication. So arithmetic overflow and thus in
incorrect value is possible.

Correct an instance of this in the inter packet delay calculation.  Fix by
ensuring one of the operands is u64 which will promote the other to u64 as
well ensuring no overflow.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/06039d8afefdbac05bcea5f397188407eba2996d; https://git.kernel.org/stable/c/252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a; https://git.kernel.org/stable/c/31dca00d0cc9f4133320d72eb7e3720badc6d6e6
CVE: CVE-2022-49405
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: r8188eu: prevent ->Ssid overflow in rtw_wx_set_scan()

This code has a check to prevent read overflow but it needs another
check to prevent writing beyond the end of the ->Ssid[] array.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/476bfda0be0f9669add92bff604ca78226cf53d1; https://git.kernel.org/stable/c/ac2eab7de458f5e1210ce1237afab40a307075c8; https://git.kernel.org/stable/c/bc10916e890948d8927a5c8c40fb5dc44be5e1b8
CVE: CVE-2022-49406
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

block: Fix potential deadlock in blk_ia_range_sysfs_show()

When being read, a sysfs attribute is already protected against removal
with the kobject node active reference counter. As a result, in
blk_ia_range_sysfs_show(), there is no need to take the queue sysfs
lock when reading the value of a range attribute. Using the queue sysfs
lock in this function creates a potential deadlock situation with the
disk removal, something that a lockdep signals with a splat when the
device is removed:

[  760.703551]  Possible unsafe locking scenario:
[  760.703551]
[  760.703554]        CPU0                    CPU1
[  760.703556]        ----                    ----
[  760.703558]   lock(&q->sysfs_lock);
[  760.703565]                                lock(kn->active#385);
[  760.703573]                                lock(&q->sysfs_lock);
[  760.703579]   lock(kn->active#385);
[  760.703587]
[  760.703587]  *** DEADLOCK ***

Solve this by removing the mutex_lock()/mutex_unlock() calls from
blk_ia_range_sysfs_show().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/41e46b3c2aa24f755b2ae9ec4ce931ba5f0d8532; https://git.kernel.org/stable/c/717b078bc745ba9a262abebed9806a17e8bbb77b; https://git.kernel.org/stable/c/dc107c805cde709866b59867ef72b[PII_REDACTED]e
CVE: CVE-2022-49408
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix memory leak in parse_apply_sb_mount_options()

If processing the on-disk mount options fails after any memory was
allocated in the ext4_fs_context, e.g. s_qf_names, then this memory is
leaked.  Fix this by calling ext4_fc_free() instead of kfree() directly.

Reproducer:

    mkfs.ext4 -F /dev/vdc
    tune2fs /dev/vdc -E mount_opts=usrjquota=file
    echo clear > /sys/kernel/debug/kmemleak
    mount /dev/vdc /vdc
    echo scan > /sys/kernel/debug/kmemleak
    sleep 5
    echo scan > /sys/kernel/debug/kmemleak
    cat /sys/kernel/debug/kmemleak
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/9ea3e[PII_REDACTED]cec31d0678d2b55b395f88491; https://git.kernel.org/stable/c/c069db76ed7b681c69159f44be96d2137e9ca989; https://git.kernel.org/stable/c/f92ded66e9d0aa20b883a2a5183973abc8f41815
CVE: CVE-2022-49410
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix potential double free in create_var_ref()

In create_var_ref(), init_var_ref() is called to initialize the fields
of variable ref_field, which is allocated in the previous function call
to create_hist_field(). Function init_var_ref() allocates the
corresponding fields such as ref_field->system, but frees these fields
when the function encounters an error. The caller later calls
destroy_hist_field() to conduct error handling, which frees the fields
and the variable itself. This results in double free of the fields which
are already freed in the previous function.

Fix this by storing NULL to the corresponding fields when they are freed
in init_var_ref().
CVSS Score: 7.8 (HIGH)
CWE: CWE-415, CWE-415
References: https://git.kernel.org/stable/c/058cb6d86b[PII_REDACTED]c936506b346aaa1eb581; https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50; https://git.kernel.org/stable/c/4fdfb15e08598711dbf50daf56a33965232daf0e
CVE: CVE-2022-49411
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bfq: Make sure bfqg for which we are queueing requests is online

Bios queued into BFQ IO scheduler can be associated with a cgroup that
was already offlined. This may then cause insertion of this bfq_group
into a service tree. But this bfq_group will get freed as soon as last
bio associated with it is completed leading to use after free issues for
service tree users. Fix the problem by making sure we always operate on
online bfq_group. If the bfq_group associated with the bio is not
online, we pick the first online parent.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/075a53b78b815301f8d3dd1ee2cd99554e34f0dd; https://git.kernel.org/stable/c/51f724bffa3403a5236597e6b75df7329c1ec6e9; https://git.kernel.org/stable/c/6ee0868b0c3ccead5907685fcdcdd0c08dfe4b0b
CVE: CVE-2022-49412
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bfq: Avoid merging queues with different parents

It can happen that the parent of a bfqq changes between the moment we
decide two queues are worth to merge (and set bic->stable_merge_bfqq)
and the moment bfq_setup_merge() is called. This can happen e.g. because
the process submitted IO for a different cgroup and thus bfqq got
reparented. It can even happen that the bfqq we are merging with has
parent cgroup that is already offline and going to be destroyed in which
case the merge can lead to use-after-free issues such as:

BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50
Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544

CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G            E     5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
Call Trace:
 <IRQ>
 dump_stack_lvl+0x46/0x5a
 print_address_description.constprop.0+0x1f/0x140
 ? __bfq_deactivate_entity+0x9cb/0xa50
 kasan_report.cold+0x7f/0x11b
 ? __bfq_deactivate_entity+0x9cb/0xa50
 __bfq_deactivate_entity+0x9cb/0xa50
 ? update_curr+0x32f/0x5d0
 bfq_deactivate_entity+0xa0/0x1d0
 bfq_del_bfqq_busy+0x28a/0x420
 ? resched_curr+0x116/0x1d0
 ? bfq_requeue_bfqq+0x70/0x70
 ? check_preempt_wakeup+0x52b/0xbc0
 __bfq_bfqq_expire+0x1a2/0x270
 bfq_bfqq_expire+0xd16/0x2160
 ? try_to_wake_up+0x4ee/0x1260
 ? bfq_end_wr_async_queues+0xe0/0xe0
 ? _raw_write_unlock_bh+0x60/0x60
 ? _raw_spin_lock_irq+0x81/0xe0
 bfq_idle_slice_timer+0x109/0x280
 ? bfq_dispatch_request+0x4870/0x4870
 __hrtimer_run_queues+0x37d/0x700
 ? enqueue_hrtimer+0x1b0/0x1b0
 ? kvm_clock_get_cycles+0xd/0x10
 ? ktime_get_update_offsets_now+0x6f/0x280
 hrtimer_interrupt+0x2c8/0x740

Fix the problem by checking that the parent of the two bfqqs we are
merging in bfq_setup_merge() is the same.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5ee21edaed09e6b25f2c007b3f326752bc89bacf; https://git.kernel.org/stable/c/8abc8763b11c35e03cc91d59fd0cd28d39f88ca9; https://git.kernel.org/stable/c/a16c65cca7d2c7ff965fdd3adc8df2156529caf1
CVE: CVE-2022-49413
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

bfq: Update cgroup information before merging bio

When the process is migrated to a different cgroup (or in case of
writeback just starts submitting bios associated with a different
cgroup) bfq_merge_bio() can operate with stale cgroup information in
bic. Thus the bio can be merged to a request from a different cgroup or
it can result in merging of bfqqs for different cgroups or bfqqs of
already dead cgroups and causing possible use-after-free issues. Fix the
problem by updating cgroup information in bfq_merge_bio().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2a1077f17169a6059992a0bbdb330e0abad1e6d9; https://git.kernel.org/stable/c/b06691af08b41dfd81052a3362514d9827b44bb1; https://git.kernel.org/stable/c/d9165200c5627a2cf4408eefabdf0058bdf95e1a
CVE: CVE-2022-49415
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ipmi:ipmb: Fix refcount leak in ipmi_ipmb_probe

of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/a508e33956b538e034ed5df619a73ec7c15bda72; https://git.kernel.org/stable/c/f22068357acc268148bd55ce77f0a3e5c86701b4
CVE: CVE-2022-49416
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix use-after-free in chanctx code

In ieee80211_vif_use_reserved_context(), when we have an
old context and the new context's replace_state is set to
IEEE80211_CHANCTX_REPLACE_NONE, we free the old context
in ieee80211_vif_use_reserved_reassign(). Therefore, we
cannot check the old_ctx anymore, so we should set it to
NULL after this point.

However, since the new_ctx replace state is clearly not
IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do
anything else in this function and can just return to
avoid accessing the freed old_ctx.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/265bec4779a38b65e86a25120370f200822dfa76; https://git.kernel.org/stable/c/2965c4cdf7ad9ce0796fac5e57debb9519ea721e; https://git.kernel.org/stable/c/4ba81e794f0fad6234f644c2da1ae14d5b95e1c4
CVE: CVE-2022-49417
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

iwlwifi: mei: fix potential NULL-ptr deref

If SKB allocation fails, continue rather than using the NULL
pointer.

Coverity CID: 1497650
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/29b81de94d62b5e2704bb5106b3e701ca8d7c7a4; https://git.kernel.org/stable/c/5d8d06fd3a02919100b28f927bcb76481ec0a0e3; https://git.kernel.org/stable/c/78488a64aea94a3336ee97f345c1496e9bc5ebdf
CVE: CVE-2022-49418
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSv4: Fix free of uninitialized nfs4_label on referral lookup.

Send along the already-allocated fattr along with nfs4_fs_locations, and
drop the memcpy of fattr.  We end up growing two more allocations, but this
fixes up a crash as:

PID: 790    TASK: ffff88811b43c000  CPU: 0   COMMAND: "ls"
 #0 [ffffc[PII_REDACTED]0] panic at ffffffff81b9bfde
 #1 [ffffc900008579c0] do_trap at ffffffff81023a9b
 #2 [ffffc90000857a10] do_error_trap at ffffffff81023b78
 #3 [ffffc90000857a58] exc_stack_segment at ffffffff81be1f45
 #4 [ffffc90000857a80] asm_exc_stack_segment at ffffffff81c009de
 #5 [ffffc90000857b08] nfs_lookup at ffffffffa0302322 [nfs]
 #6 [ffffc90000857b70] __lookup_slow at ffffffff813a4a5f
 #7 [ffffc90000857c60] walk_component at ffffffff813a86c4
 #8 [ffffc90000857cb8] path_lookupat at ffffffff813a9553
 #9 [ffffc90000857cf0] filename_lookup at ffffffff813ab86b
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/[PII_REDACTED]d95ba9f72906e2b65e536aa5807d64; https://git.kernel.org/stable/c/c3ed222745d9ad7b69299b349a64ba533c64a34f
CVE: CVE-2022-49419
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup

Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather
than .remove") fixed a use-after-free error due the vesafb driver freeing
the fb_info in the .remove handler instead of doing it in .fb_destroy.

This can happen if the .fb_destroy callback is executed after the .remove
callback, since the former tries to access a pointer freed by the latter.

But that change didn't take into account that another possible scenario is
that .fb_destroy is called before the .remove callback. For example, if no
process has the fbdev chardev opened by the time the driver is removed.

If that's the case, fb_info will be freed when unregister_framebuffer() is
called, making the fb_info pointer accessed in vesafb_remove() after that
to no longer be valid.

To prevent that, move the expression containing the info->par to happen
before the unregister_framebuffer() function call.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0fac5f8fb1bc2fc4f8714bf5e743c9cc3f547c63; https://git.kernel.org/stable/c/acde4003efc[PII_REDACTED]638484d8f13f2e99a3; https://git.kernel.org/stable/c/d260cad015945d1f4bb9b028a096f648506106a2
CVE: CVE-2022-49420
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: annotate races around sk->sk_bound_dev_if

UDP sendmsg() is lockless, and reads sk->sk_bound_dev_if while
this field can be changed by another thread.

Adds minimal annotations to avoid KCSAN splats for UDP.
Following patches will add more annotations to potential lockless readers.

BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg

write to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0:
 __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221
 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272
 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576
 __sys_connect_file net/socket.c:1900 [inline]
 __sys_connect+0x197/0x1b0 net/socket.c:1917
 __do_sys_connect net/socket.c:1927 [inline]
 __se_sys_connect net/socket.c:1924 [inline]
 __x64_sys_connect+0x3d/0x50 net/socket.c:1924
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

read to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1:
 udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436
 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652
 sock_sendmsg_nosec net/socket.c:705 [inline]
 sock_sendmsg net/socket.c:725 [inline]
 ____sys_sendmsg+0x39a/0x510 net/socket.c:2413
 ___sys_sendmsg net/socket.c:2467 [inline]
 __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553
 __do_sys_sendmmsg net/socket.c:2582 [inline]
 __se_sys_sendmmsg net/socket.c:2579 [inline]
 __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

value changed: 0x00000000 -> 0xffffff9b

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G        W         5.18.0-rc1-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

I chose to not add Fixes: tag because race has minor consequences
and stable teams busy enough.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/20b2f61797873a2b18b5ff1a304ad2674fa1e0a5; https://git.kernel.org/stable/c/4c971d2f3548e4f11b1460ac048f5307e4b39fdb
CVE: CVE-2022-49421
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup

of_parse_phandle() 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/2e2e2c71b[PII_REDACTED]392edbf5d08cdbc0b138b; https://git.kernel.org/stable/c/38d245cebf545338a6bc1c7762023de3fbecd7b7; https://git.kernel.org/stable/c/51eb1bb6baeb478538dd4ec6459fd68c44a855b1
CVE: CVE-2022-49422
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Fix the error handling path in idxd_cdev_register()

If a call to alloc_chrdev_region() fails, the already allocated resources
are leaking.

Add the needed error handling path to fix the leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5e88561eceb34ae3f88451c2b8e30fe403484189; https://git.kernel.org/stable/c/6073af78156b8c3fc1198f8bcc190b7ac3ac0143; https://git.kernel.org/stable/c/aab08c1aac01097815fbcf10fce7021d2396a31f