huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-49974: kernel: HID: nintendo: fix rumble worker null pointer deref
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

HID: nintendo: fix rumble worker null pointer deref

We can dereference a null pointer trying to queue work to a destroyed
workqueue.

If the device is disconnected, nintendo_hid_remove is called, in which
the rumble_queue is destroyed. Avoid using that queue to defer rumble
work once the controller state is set to JOYCON_CTLR_STATE_REMOVED.

This eliminates the null pointer dereference.


Affected upstream versions: 5.16
Fixed upstream versions: 0, 5.19.7, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7c6e6c334154be16740b44dcd7638fb510b9bd91
CVE-2022-49979: kernel: net: fix refcount bug in sk_psock_get (2)
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: fix refcount bug in sk_psock_get (2)

Syzkaller reports refcount bug as follows:
------------[ cut here ]------------
refcount_t: saturated; leaking memory.
WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19
Modules linked in:
CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0
 <TASK>
 __refcount_add_not_zero include/linux/refcount.h:163 [inline]
 __refcount_inc_not_zero include/linux/refcount.h:227 [inline]
 refcount_inc_not_zero include/linux/refcount.h:245 [inline]
 sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439
 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091
 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983
 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057
 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659
 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682
 sk_backlog_rcv include/net/sock.h:1061 [inline]
 __release_sock+0x134/0x3b0 net/core/sock.c:2849
 release_sock+0x54/0x1b0 net/core/sock.c:3404
 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909
 __sys_shutdown_sock net/socket.c:2331 [inline]
 __sys_shutdown_sock net/socket.c:2325 [inline]
 __sys_shutdown+0xf1/0x1b0 net/socket.c:2343
 __do_sys_shutdown net/socket.c:2351 [inline]
 __se_sys_shutdown net/socket.c:2349 [inline]
 __x64_sys_shutdown+0x50/0x70 net/socket.c:2349
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
 </TASK>

During SMC fallback process in connect syscall, kernel will
replaces TCP with SMC. In order to forward wakeup
smc socket waitqueue after fallback, kernel will sets
clcsk->sk_user_data to origin smc socket in
smc_fback_replace_callbacks().

Later, in shutdown syscall, kernel will calls
sk_psock_get(), which treats the clcsk->sk_user_data
as psock type, triggering the refcnt warning.

So, the root cause is that smc and psock, both will use
sk_user_data field. So they will mismatch this field
easily.

This patch solves it by using another bit(defined as
SK_USER_DATA_PSOCK) in PTRMASK, to mark whether
sk_user_data points to a psock object or not.
This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e
("net, sk_msg: Clear sk_user_data pointer on clone if tagged").

For there will possibly be more flags in the sk_user_data field,
this patch also refactor sk_user_data flags code to be more generic
to improve its maintainability.


Affected upstream versions: 5.15.22 < 5.15.65, 5.16.8 < 5.17, 5.17
Fixed upstream versions: 0, 5.15.65, 5.17, 5.19.7, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a5d1cb908131e939bd8b63b8e5e23365bbc2edaf
CVE-2022-49980: kernel: USB: gadget: Fix use-after-free Read in usb_udc_uevent()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

USB: gadget: Fix use-after-free Read in usb_udc_uevent()

The syzbot fuzzer found a race between uevent callbacks and gadget
driver unregistration that can cause a use-after-free bug:

---------------------------------------------------------------
BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130
drivers/usb/gadget/udc/core.c:1732
Read of size 8 at addr ffff888078ce2050 by task udevd/2968

CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
06/29/2022
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:317 [inline]
 print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495
 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732
 dev_uevent+0x290/0x770 drivers/base/core.c:2424
---------------------------------------------------------------

The bug occurs because usb_udc_uevent() dereferences udc->driver but
does so without acquiring the udc_lock mutex, which protects this
field.  If the gadget driver is unbound from the udc concurrently with
uevent processing, the driver structure may be accessed after it has
been deallocated.

To prevent the race, we make sure that the routine holds the mutex
around the racing accesses.


Affected upstream versions: 3.1
Fixed upstream versions: 0, 5.19.7, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f44b0b95d50fffeca036e1ba36770390e0b519dd
CVE-2022-49981: kernel: HID: hidraw: fix memory leak in hidraw_release()
Component: kernel
Severity: Low
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

A flaw was found in the HID device support in the Linux kernel. A missing release of allocated memory will cause a memory leak, potentially impacting system performance and resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 9.2 via RHSA-2023:2458 [1].

[1]. https://access.redhat.com/errata/RHSA-2023:2458

Affected upstream versions: 2.6.24
Fixed upstream versions: 0, 4.14.292, 4.19.257, 4.9.327, 5.10.141, 5.15.65, 5.19.7, 5.4.212, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1bea0bbf66001b0c7bf239a4d70eaf47824d3feb
CVE-2022-49982: kernel: media: pvrusb2: fix memory leak in pvr_probe
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

media: pvrusb2: fix memory leak in pvr_probe

The error handling code in pvr2_hdw_create forgets to unregister the
v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create,
it calls pvr2_context_destroy to destroy context, but mp->hdw is NULL,
which leads to that pvr2_hdw_destroy directly returns.

Fix this by adding v4l2_device_unregister to decrease the refcount of
usb interface.


Affected upstream versions: 2.6.30
Fixed upstream versions: 0, 4.14.292, 4.19.257, 4.9.327, 5.10.141, 5.15.65, 5.19.7, 5.4.212, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2fe46195d2f0d5d09ea65433aefe47a4d0d0ff4d
CVE-2022-49984: kernel: HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

A flaw was found in the hid-steam module in the Linux kernel. A NULL pointer dereference can be triggered when a malicious device fails to submit a feature report, resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 9.2 via RHSA-2023:2458 [1].

[1]. https://access.redhat.com/errata/RHSA-2023:2458

Affected upstream versions: 4.18
Fixed upstream versions: 0, 4.19.257, 5.10.141, 5.15.65, 5.19.7, 5.4.212, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c20d03b82a2e3ddbb555dad4d4f3374a9763222c
CVE-2022-49985: kernel: bpf: Don't use tnum_range on array range checking for poke descriptors
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

bpf: Don't use tnum_range on array range checking for poke descriptors

Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which
is based on a customized syzkaller:

  BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0
  Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489
  CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
  1.13.0-1ubuntu1.1 04/01/2014
  Call Trace:
   <TASK>
   dump_stack_lvl+0x9c/0xc9
   print_address_description.constprop.0+0x1f/0x1f0
   ? bpf_int_jit_compile+0x1257/0x13f0
   kasan_report.cold+0xeb/0x197
   ? kvmalloc_node+0x170/0x200
   ? bpf_int_jit_compile+0x1257/0x13f0
   bpf_int_jit_compile+0x1257/0x13f0
   ? arch_prepare_bpf_dispatcher+0xd0/0xd0
   ? rcu_read_lock_sched_held+0x43/0x70
   bpf_prog_select_runtime+0x3e8/0x640
   ? bpf_obj_name_cpy+0x149/0x1b0
   bpf_prog_load+0x102f/0x2220
   ? __bpf_prog_put.constprop.0+0x220/0x220
   ? find_held_lock+0x2c/0x110
   ? __might_fault+0xd6/0x180
   ? lock_downgrade+0x6e0/0x6e0
   ? lock_is_held_type+0xa6/0x120
   ? __might_fault+0x147/0x180
   __sys_bpf+0x137b/0x6070
   ? bpf_perf_link_attach+0x530/0x530
   ? new_sync_read+0x600/0x600
   ? __fget_files+0x255/0x450
   ? lock_downgrade+0x6e0/0x6e0
   ? fput+0x30/0x1a0
   ? ksys_write+0x1a8/0x260
   __x64_sys_bpf+0x7a/0xc0
   ? syscall_enter_from_user_mode+0x21/0x70
   do_syscall_64+0x3b/0x90
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
  RIP: 0033:0x7f917c4e2c2d

The problem here is that a range of tnum_range(0, map->max_entries - 1) has
limited ability to represent the concrete tight range with the tnum as the
set of resulting states from value + mask can result in a superset of the
actual intended range, and as such a tnum_in(range, reg->var_off) check may
yield true when it shouldn't, for example tnum_range(0, 2) would result in
00XX -> v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here
represented by a less precise superset of {0, 1, 2, 3}. As the register is
known const scalar, really just use the concrete reg->var_off.value for the
upper index check.


Affected upstream versions: 5.5
Fixed upstream versions: 0, 5.10.140, 5.15.64, 5.19.6, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e8979807178434db8ceaa84dfcd44363e71e50bb
CVE-2022-49986: kernel: scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq

storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it
doesn't need to make forward progress under memory pressure.  Marking this
workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a
non-WQ_MEM_RECLAIM workqueue.  In the current state it causes the following
warning:

[   14.506347] ------------[ cut here ]------------
[   14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn
[   14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130
[   14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu
[   14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[   14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun
[   14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130
		<-snip->
[   14.506408] Call Trace:
[   14.506412]  __flush_work+0xf1/0x1c0
[   14.506414]  __cancel_work_timer+0x12f/0x1b0
[   14.506417]  ? kernfs_put+0xf0/0x190
[   14.506418]  cancel_delayed_work_sync+0x13/0x20
[   14.506420]  disk_block_events+0x78/0x80
[   14.506421]  del_gendisk+0x3d/0x2f0
[   14.506423]  sr_remove+0x28/0x70
[   14.506427]  device_release_driver_internal+0xef/0x1c0
[   14.506428]  device_release_driver+0x12/0x20
[   14.506429]  bus_remove_device+0xe1/0x150
[   14.506431]  device_del+0x167/0x380
[   14.506432]  __scsi_remove_device+0x11d/0x150
[   14.506433]  scsi_remove_device+0x26/0x40
[   14.506434]  storvsc_remove_lun+0x40/0x60
[   14.506436]  process_one_work+0x209/0x400
[   14.506437]  worker_thread+0x34/0x400
[   14.506439]  kthread+0x121/0x140
[   14.506440]  ? process_one_work+0x400/0x400
[   14.506441]  ? kthread_park+0x90/0x90
[   14.506443]  ret_from_fork+0x35/0x40
[   14.506445] ---[ end trace 2d9633159fdc6ee7 ]---


Affected upstream versions: 4.15
Fixed upstream versions: 0, 4.19.257, 5.10.140, 5.15.64, 5.19.6, 5.4.212, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b692c238ddfa61f00d97c4c1f021425d132ba96f
CVE-2022-49990: kernel: s390: fix double free of GS and RI CBs on fork() failure
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

s390: fix double free of GS and RI CBs on fork() failure

The pointers for guarded storage and runtime instrumentation control
blocks are stored in the thread_struct of the associated task. These
pointers are initially copied on fork() via arch_dup_task_struct()
and then cleared via copy_thread() before fork() returns. If fork()
happens to fail after the initial task dup and before copy_thread(),
the newly allocated task and associated thread_struct memory are
freed via free_task() -> arch_release_task_struct(). This results in
a double free of the guarded storage and runtime info structs
because the fields in the failed task still refer to memory
associated with the source task.

This problem can manifest as a BUG_ON() in set_freepointer() (with
CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled)
when running trinity syscall fuzz tests on s390x. To avoid this
problem, clear the associated pointer fields in
arch_dup_task_struct() immediately after the new task is copied.
Note that the RI flag is still cleared in copy_thread() because it
resides in thread stack memory and that is where stack info is
copied.


Affected upstream versions: 4.4.105 < 4.5, 4.9.68 < 4.10, 4.14.5 < 4.15, 4.15
Fixed upstream versions: 0, 4.10, 4.15, 4.19.257, 4.5, 5.10.140, 5.15.64, 5.19.6, 5.4.212, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 25a95303b9e513cd2978aacc385d06e6fec23d07
CVE-2022-49991: kernel: mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte
Component: kernel
Severity: Moderate
CWE: CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte

In MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the page
cache are installed in the ptes.  But hugepage_add_new_anon_rmap is called
for them mistakenly because they're not vm_shared.  This will corrupt the
page->mapping used by page cache code.


Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.65, 5.19.6, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: da60ddd80d09f8371fbba1a238a4b318d13ba698
CVE-2022-49992: kernel: mm/mprotect: only reference swap pfn page if type match
Component: kernel
Severity: Moderate
CWE: CWE-843 (Access of Resource Using Incompatible Type ('Type Confusion'))
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

mm/mprotect: only reference swap pfn page if type match

Yu Zhao reported a bug after the commit "mm/swap: Add swp_offset_pfn() to
fetch PFN from swap entry" added a check in swp_offset_pfn() for swap type [1]:

  kernel BUG at include/linux/swapops.h:117!
  CPU: 46 PID: 5245 Comm: EventManager_De Tainted: G S         O L 6.0.0-dbg-DEV #2
  RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0
  Code: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6
  c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e <0f> 0b
  48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48
  RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282
  RAX: 00000000ffffffe8 RBX: 0c00000000000000 RCX: ffffcd5440000000
  RDX: 1ffffffffff7a80a RSI: 0000000000000000 RDI: 0c0000000000042b
  RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: 0000000000000000
  R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738
  R13: 000000000000042b R14: 0c0000000000042b R15: 1ffffffffff7a80a
  FS:  00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000440d035b3180 CR3: 0000002243176004 CR4: 00000000003706e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   <TASK>
   change_pte_range+0x36e/0x880
   change_p4d_range+0x2e8/0x670
   change_protection_range+0x14e/0x2c0
   mprotect_fixup+0x1ee/0x330
   do_mprotect_pkey+0x34c/0x440
   __x64_sys_mprotect+0x1d/0x30

It triggers because pfn_swap_entry_to_page() could be called upon e.g. a
genuine swap entry.

Fix it by only calling it when it's a write migration entry where the page*
is used.

[1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/


Affected upstream versions: 5.19
Fixed upstream versions: 0, 5.19.6, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5fcf81e308d1f4ae95f31690d2a80b7061385ff9
CVE-2022-49993: kernel: loop: Check for overflow while configuring loop
Component: kernel
Severity: Moderate
CWE: CWE-681 (Incorrect Conversion between Numeric Types)
CVSS v3: 5.8 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

loop: Check for overflow while configuring loop

The userspace can configure a loop using an ioctl call, wherein
a configuration of type loop_config is passed (see lo_ioctl()'s
case on line 1550 of drivers/block/loop.c). This proceeds to call
loop_configure() which in turn calls loop_set_status_from_info()
(see line 1050 of loop.c), passing &config->info which is of type
loop_info64*. This function then sets the appropriate values, like
the offset.

loop_device has lo_offset of type loff_t (see line 52 of loop.c),
which is typdef-chained to long long, whereas loop_info64 has
lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).

The function directly copies offset from info to the device as
follows (See line 980 of loop.c):
	lo->lo_offset = info->lo_offset;

This results in an overflow, which triggers a warning in iomap_iter()
due to a call to iomap_iter_done() which has:
	WARN_ON_ONCE(iter->iomap.offset > iter->pos);

Thus, check for negative value during loop_set_status_from_info().

Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e


Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 4.14.292, 4.19.312, 4.9.327, 5.10.140, 5.15.64, 5.19.6, 5.4.274, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 18e28817cb516b39de6281f6db9b0618b2cc7b42
CVE-2022-49994: kernel: bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem
Component: kernel
Severity: Low
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem

The vmemmap pages is marked by kmemleak when allocated from memblock. 
Remove it from kmemleak when freeing the page.  Otherwise, when we reuse
the page, kmemleak may report such an error and then stop working.

 kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing)
 kmemleak: Kernel memory leak detector disabled
 kmemleak: Object 0xffff98fb6be00000 (size 335544320):
 kmemleak:   comm "swapper", pid 0, jiffies 4294892296
 kmemleak:   min_count = 0
 kmemleak:   count = 0
 kmemleak:   flags = 0x1
 kmemleak:   checksum = 0
 kmemleak:   backtrace:


Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.64, 5.19.6, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 16a12ee619e39e8112f61b603255c16b73b6264b
CVE-2022-49995: kernel: writeback: avoid use-after-free after removing device
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired Pointer Dereference)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

writeback: avoid use-after-free after removing device

When a disk is removed, bdi_unregister gets called to stop further
writeback and wait for associated delayed work to complete.  However,
wb_inode_writeback_end() may schedule bandwidth estimation dwork after
this has completed, which can result in the timer attempting to access the
just freed bdi_writeback.

Fix this by checking if the bdi_writeback is alive, similar to when
scheduling writeback work.

Since this requires wb->work_lock, and wb_inode_writeback_end() may get
called from interrupt, switch wb->work_lock to an irqsafe lock.


Affected upstream versions: 5.15
Fixed upstream versions: 0, 5.15.64, 5.19.6, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f96b9f7c1676923bce871e728bb49c0dfa5013cc
CVE-2022-50001: kernel: netfilter: nft_tproxy: restrict to prerouting hook
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_tproxy: restrict to prerouting hook

TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this.
This fixes a crash (null dereference) when using tproxy from e.g. output.


Affected upstream versions: 4.19
Fixed upstream versions: 0, 4.19.273, 5.10.169, 5.15.95, 5.19.6, 5.4.232, 6.0
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0b21edf4cc13516716848e0a4fdf726aa2a62cd9