huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-49297: kernel: nbd: fix io hung while disconnecting device
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-02-26T00:00:00+00:00

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

nbd: fix io hung while disconnecting device

In our tests, "qemu-nbd" triggers a io hung:

INFO: task qemu-nbd:11445 blocked for more than 368 seconds.
      Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:qemu-nbd        state:D stack:    0 pid:11445 ppid:     1 flags:0x00000000
Call Trace:
 <TASK>
 __schedule+0x480/0x1050
 ? _raw_spin_lock_irqsave+0x3e/0xb0
 schedule+0x9c/0x1b0
 blk_mq_freeze_queue_wait+0x9d/0xf0
 ? ipi_rseq+0x70/0x70
 blk_mq_freeze_queue+0x2b/0x40
 nbd_add_socket+0x6b/0x270 [nbd]
 nbd_ioctl+0x383/0x510 [nbd]
 blkdev_ioctl+0x18e/0x3e0
 __x64_sys_ioctl+0xac/0x120
 do_syscall_64+0x35/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fd8ff706577
RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577
RDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000f
RBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0
R10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006d
R13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0

"qemu-ndb -d" will call ioctl 'NBD_DISCONNECT' first, however, following
message was found:

block nbd0: Send disconnect failed -32

Which indicate that something is wrong with the server. Then,
"qemu-nbd -d" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clear
requests after commit 2516ab1543fd("nbd: only clear the queue on device
teardown"). And in the meantime, request can't complete through timeout
because nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', which
means such request will never be completed in this situation.

Now that the flag 'NBD_CMD_INFLIGHT' can make sure requests won't
complete multiple times, switch back to call nbd_clear_sock() in
nbd_clear_sock_ioctl(), so that inflight requests can be cleared.


Affected upstream versions: 4.12
Fixed upstream versions: 0, 4.14.283, 4.19.247, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 67e403136a0e1a55fef6a05f103a3979a39ad3fd
CVE-2022-49306: kernel: usb: dwc3: host: Stop setting the ACPI companion
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-02-26T00:00:00+00:00

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

usb: dwc3: host: Stop setting the ACPI companion

It is no longer needed. The sysdev pointer is now used when
assigning the ACPI companions to the xHCI ports and USB
devices.

Assigning the ACPI companion here resulted in the
fwnode->secondary pointer to be replaced also for the parent
dwc3 device since the primary fwnode (the ACPI companion)
was shared. That was unintentional and it created potential
side effects like resource leaks.


Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d7f35934f7ab67bfd9adabc84207e59da9c19108
CVE-2022-49308: kernel: extcon: Modify extcon device to be created after driver data is set
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
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-02-26T00:00:00+00:00

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

extcon: Modify extcon device to be created after driver data is set

Currently, someone can invoke the sysfs such as state_show()
intermittently before dev_set_drvdata() is done.
And it can be a cause of kernel Oops because of edev is Null at that time.
So modified the driver registration to after setting drviver data.

- Oops's backtrace.

Backtrace:
[<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show)
[<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show)
[<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show)
[<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read)
[<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read)
[<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read)
[<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read)
[<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read)
[<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read)
[<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return)


Affected upstream versions: 3.5
Fixed upstream versions: 0, 4.14.283, 4.19.247, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6e721f3ad0535b24f19a62420f4da95212cf069c
CVE-2022-49316: kernel: NFSv4: Don't hold the layoutget locks across multiple RPC calls
Component: kernel
Severity: Moderate
CWE: CWE-667 (Improper Locking)
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-02-26T00:00:00+00:00

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

NFSv4: Don't hold the layoutget locks across multiple RPC calls

When doing layoutget as part of the open() compound, we have to be
careful to release the layout locks before we can call any further RPC
calls, such as setattr(). The reason is that those calls could trigger
a recall, which could deadlock.


Affected upstream versions: 4.18
Fixed upstream versions: 0, 4.19.247, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6b3fc1496e7227cd6a39a80bbfb7588ef7c7a010
CVE-2022-49319: kernel: iommu/arm-smmu-v3: check return value after calling platform_get_resource()
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

iommu/arm-smmu-v3: 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.


Affected upstream versions: 4.2
Fixed upstream versions: 0, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 54c1e0e3bbcab2abe25b2874a43050ae5df87831
CVE-2022-49322: kernel: tracing: Fix sleeping function called from invalid context on RT kernel
Component: kernel
Severity: Low
CWE: CWE-667 (Improper Locking)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

tracing: Fix sleeping function called from invalid context on RT kernel

When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the
cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the
atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,
these locks are replaced with sleepable rt-spinlock, so the stack calltrace will
be triggered.
Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start
tp_printk=1" enabled.

 BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
 preempt_count: 2, expected: 0
 RCU nest depth: 0, expected: 0
 Preemption disabled at:
 [<ffffffff8992303e>] try_to_wake_up+0x7e/0xba0
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
 Call Trace:
  <TASK>
  dump_stack_lvl+0x60/0x8c
  dump_stack+0x10/0x12
  __might_resched.cold+0x11d/0x155
  rt_spin_lock+0x40/0x70
  trace_event_buffer_commit+0x2fa/0x4c0
  ? map_vsyscall+0x93/0x93
  trace_event_raw_event_initcall_start+0xbe/0x110
  ? perf_trace_initcall_finish+0x210/0x210
  ? probe_sched_wakeup+0x34/0x40
  ? ttwu_do_wakeup+0xda/0x310
  ? trace_hardirqs_on+0x35/0x170
  ? map_vsyscall+0x93/0x93
  do_one_initcall+0x217/0x3c0
  ? trace_event_raw_event_initcall_level+0x170/0x170
  ? push_cpu_stop+0x400/0x400
  ? cblist_init_generic+0x241/0x290
  kernel_init_freeable+0x1ac/0x347
  ? _raw_spin_unlock_irq+0x65/0x80
  ? rest_init+0xf0/0xf0
  kernel_init+0x1e/0x150
  ret_from_fork+0x22/0x30
  </TASK>


Affected upstream versions: 3.19
Fixed upstream versions: 0, 4.14.283, 4.19.247, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: be1f323fb9d9b14a505ca22d742d321769454de1
CVE-2022-49323: kernel: iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()
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-02-26T00:00:00+00:00

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

iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()

It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code.


Affected upstream versions: 4.11
Fixed upstream versions: 0, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3660db29b0305f9a1d95979c7af0f5db6ea99f5d
CVE-2022-49325: kernel: tcp: add accessors to read/set tp->snd_cwnd
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
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-02-26T00:00:00+00:00

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

tcp: add accessors to read/set tp->snd_cwnd

We had various bugs over the years with code
breaking the assumption that tp->snd_cwnd is greater
than zero.

Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) added
in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")
can trigger, and without a repro we would have to spend
considerable time finding the bug.

Instead of complaining too late, we want to catch where
and when tp->snd_cwnd is set to an illegal value.


Affected upstream versions: 2.6.17
Fixed upstream versions: 0, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3308676ec525901bf1656014003c443a60730a04
CVE-2022-49328: kernel: mt76: fix use-after-free by removing a non-RCU wcid pointer
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-02-26T00:00:00+00:00

A vulnerability was found in the Linux kernel's mt76 wi-fi driver. A concurrency bug causes the `mtxq` TX queue to maintain a raw pointer to a `wcid` structure (`mtxq->wcid`) that might be freed by the time it is accessed. This issue can lead to a use-after-free scenario, leading to system instability, memory corruption, and potentially arbitrary code execution.


Affected upstream versions: 4.16
Fixed upstream versions: 0, 5.15.58, 5.17.14, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4448327b41738dbfcda680eb4935ff835568f468
CVE-2022-49329: kernel: vduse: Fix NULL pointer dereference on sysfs access
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-02-26T00:00:00+00:00

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

vduse: Fix NULL pointer dereference on sysfs access

The control device has no drvdata. So we will get a
NULL pointer dereference when accessing control
device's msg_timeout attribute via sysfs:

[ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8
[ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271)
[ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094)
[ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59)
[ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088)
[ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164)
[ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230)
[ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041)
[ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238)
[ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1))
[ 132.876319][ T3644] kernel_read (fs/read_write.c:459)
[ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94)
[ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186)
[ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207)
[ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189)
[ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132)
[ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419)

To fix it, don't create the unneeded attribute for
control device anymore.


Affected upstream versions: 5.15
Fixed upstream versions: 0, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3a7a81f4835dfda11f39fdd27586da14331896eb
CVE-2022-49332: kernel: scsi: lpfc: Address NULL pointer dereference after starget_to_rport()
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-02-26T00:00:00+00:00

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

scsi: lpfc: Address NULL pointer dereference after starget_to_rport()

Calls to starget_to_rport() may return NULL.  Add check for NULL rport
before dereference.


Affected upstream versions: 5.18
Fixed upstream versions: 0, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 68fcff1127e4995ddbd4b6861892a25c23db3f70
CVE-2022-49334: kernel: mm/huge_memory: Fix xarray node memory leak
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-02-26T00:00:00+00:00

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

mm/huge_memory: Fix xarray node memory leak

If xas_split_alloc() fails to allocate the necessary nodes to complete the
xarray entry split, it sets the xa_state to -ENOMEM, which xas_nomem()
then interprets as "Please allocate more memory", not as "Please free
any unnecessary memory" (which was the intended outcome).  It's confusing
to use xas_nomem() to free memory in this context, so call xas_destroy()
instead.


Affected upstream versions: 5.17
Fixed upstream versions: 0, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c0c84962e297927ba57fd6ddc2bb000c9d149655
CVE-2022-49339: kernel: net: ipv6: unexport __init-annotated seg6_hmac_init()
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-02-26T00:00:00+00:00

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

net: ipv6: unexport __init-annotated seg6_hmac_init()

EXPORT_SYMBOL and __init is a bad combination because the .init.text
section is freed up after the initialization. Hence, modules cannot
use symbols annotated __init. The access to a freed symbol may end up
with kernel panic.

modpost used to detect it, but it has been broken for a decade.

Recently, I fixed modpost so it started to warn it again, then this
showed up in linux-next builds.

There are two ways to fix it:

  - Remove __init
  - Remove EXPORT_SYMBOL

I chose the latter for this case because the caller (net/ipv6/seg6.c)
and the callee (net/ipv6/seg6_hmac.c) belong to the same module.
It seems an internal function call in ipv6.ko.


Affected upstream versions: 4.10
Fixed upstream versions: 0, 4.14.283, 4.19.247, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 64aef8efe96c1616142c4476a05731306fc4494e
CVE-2022-49340: kernel: ip_gre: test csum_start instead of transport header
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-02-26T00:00:00+00:00

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

ip_gre: test csum_start instead of transport header

GRE with TUNNEL_CSUM will apply local checksum offload on
CHECKSUM_PARTIAL packets.

ipgre_xmit must validate csum_start after an optional skb_pull,
else lco_csum may trigger an overflow. The original check was

	if (csum && skb_checksum_start(skb) < skb->data)
		return -EINVAL;

This had false positives when skb_checksum_start is undefined:
when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement
was straightforward

	if (csum && skb->ip_summed == CHECKSUM_PARTIAL &&
	    skb_checksum_start(skb) < skb->data)
		return -EINVAL;

But was eventually revised more thoroughly:
- restrict the check to the only branch where needed, in an
  uncommon GRE path that uses header_ops and calls skb_pull.
- test skb_transport_header, which is set along with csum_start
  in skb_partial_csum_set in the normal header_ops datapath.

Turns out skbs can arrive in this branch without the transport
header set, e.g., through BPF redirection.

Revise the check back to check csum_start directly, and only if
CHECKSUM_PARTIAL. Do leave the check in the updated location.
Check field regardless of whether TUNNEL_CSUM is configured.


Affected upstream versions: 4.19.207 < 4.19.247, 5.4.148 < 5.4.198, 5.10.68 < 5.10.122, 5.14.7 < 5.15, 5.15
Fixed upstream versions: 0, 4.19.247, 5.10.122, 5.15, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7596bd7920985f7fc8579a92e48bc53ce4475b21
CVE-2022-49343: kernel: ext4: avoid cycles in directory h-tree
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-02-26T00:00:00+00:00

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

ext4: avoid cycles in directory h-tree

A maliciously corrupted filesystem can contain cycles in the h-tree
stored inside a directory. That can easily lead to the kernel corrupting
tree nodes that were already verified under its hands while doing a node
split and consequently accessing unallocated memory. Fix the problem by
verifying traversed block numbers are unique.


Affected upstream versions: 2.6.19
Fixed upstream versions: 0, 4.14.283, 4.19.247, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 24b8206fec1db21d7e82f21f0b2ff5e5672cf5b3
CVE-2022-49345: kernel: net: xfrm: unexport __init-annotated xfrm4_protocol_init()
Component: kernel
Severity: Low
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

net: xfrm: unexport __init-annotated xfrm4_protocol_init()

EXPORT_SYMBOL and __init is a bad combination because the .init.text
section is freed up after the initialization. Hence, modules cannot
use symbols annotated __init. The access to a freed symbol may end up
with kernel panic.

modpost used to detect it, but it has been broken for a decade.

Recently, I fixed modpost so it started to warn it again, then this
showed up in linux-next builds.

There are two ways to fix it:

  - Remove __init
  - Remove EXPORT_SYMBOL

I chose the latter for this case because the only in-tree call-site,
net/ipv4/xfrm4_policy.c is never compiled as modular.
(CONFIG_XFRM is boolean)


Affected upstream versions: 3.15
Fixed upstream versions: 0, 4.14.283, 4.19.247, 4.9.318, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c58d82a1264813e69119c13e9804e2e60b664ad5
CVE-2022-49348: kernel: ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state
Component: kernel
Severity: Moderate
CWE: CWE-617 (Reachable Assertion)
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-02-26T00:00:00+00:00

A flaw was found in the ext4 module in the Linux kernel. A specially crafted filesystem can cause an assertion failure when a specific operation is performed, possibly resulting in system instability and a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 9.1 via RHSA-2022:8267 [1].

[1]. https://access.redhat.com/errata/RHSA-2022:8267

Affected upstream versions: 5.10
Fixed upstream versions: 0, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cc5b09cb6dacd4b32640537929ab4ee8fb2b9e04
CVE-2022-49350: kernel: net: mdio: unexport __init-annotated mdio_bus_init()
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-02-26T00:00:00+00:00

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

net: mdio: unexport __init-annotated mdio_bus_init()

EXPORT_SYMBOL and __init is a bad combination because the .init.text
section is freed up after the initialization. Hence, modules cannot
use symbols annotated __init. The access to a freed symbol may end up
with kernel panic.

modpost used to detect it, but it has been broken for a decade.

Recently, I fixed modpost so it started to warn it again, then this
showed up in linux-next builds.

There are two ways to fix it:

  - Remove __init
  - Remove EXPORT_SYMBOL

I chose the latter for this case because the only in-tree call-site,
drivers/net/phy/phy_device.c is never compiled as modular.
(CONFIG_PHYLIB is boolean)


Affected upstream versions: 4.12
Fixed upstream versions: 0, 4.14.283, 4.19.247, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ab64ec2c75683f30ccde9eaaf0761002f901aa12