deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-48810
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure path

ip[6]mr_free_table() can only be called under RTNL lock.

RTNL: assertion failed at net/core/dev.c (10367)
WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367
Modules linked in:
CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367
Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee
RSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286
RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece
RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: ffffffff815f3d6e R11: [PII_REDACTED] R12: 00000000fffffff4
R13: dffffc[PII_REDACTED] R14: ffffc900046ff750 R15: ffff88807b7dc000
FS:  00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4:[PII_REDACTED]3506e0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509
 ip6mr_free_table net/ipv6/ip6mr.c:389 [inline]
 ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline]
 ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline]
 ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298
 ops_init+0xaf/0x470 net/core/net_namespace.c:140
 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331
 copy_net_ns+0x318/0x760 net/core/net_namespace.c:475
 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178
 copy_process+0x2e0c/0x7300 kernel/fork.c:2167
 kernel_clone+0xe7/0xab0 kernel/fork.c:2555
 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672
 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+0x44/0xae
RIP: 0033:0x7f4ab89f9059
Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f.
RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: [PII_REDACTED]
RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: 00007f4ab8a5308d R08: [PII_REDACTED] R09: [PII_REDACTED]
R10:[PII_REDACTED]0002c0 R11: [PII_REDACTED] R12: [PII_REDACTED]
R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: [PII_REDACTED]
 </TASK>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/09ac0fcb0a82d647f2c61d3d488d367b7ee5bd51; https://git.kernel.org/stable/c/12b6703e9546902c56b4b9048b893ad49d62bdd4; https://git.kernel.org/stable/c/16dcfde98a25340ff0f7879a16bea141d824a196
CVE: CVE-2022-48811
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ibmvnic: don't release napi in __ibmvnic_open()

If __ibmvnic_open() encounters an error such as when setting link state,
it calls release_resources() which frees the napi structures needlessly.
Instead, have __ibmvnic_open() only clean up the work it did so far (i.e.
disable napi and irqs) and leave the rest to the callers.

If caller of __ibmvnic_open() is ibmvnic_open(), it should release the
resources immediately. If the caller is do_reset() or do_hard_reset(),
they will release the resources on the next reset.

This fixes following crash that occurred when running the drmgr command
several times to add/remove a vnic interface:

	[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
	[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
	[102056] ibmvnic 30000003 env3: Replenished 8 pools
	Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
	BUG: Kernel NULL pointer dereference on read at 0x00000010
	Faulting instruction address: 0xc000000000a3c840
	Oops: Kernel access of bad area, sig: 11 [#1]
	LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
	...
	CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1
	Workqueue: events_long __ibmvnic_reset [ibmvnic]
	NIP:  c000000000a3c840 LR: c[PII_REDACTED]b5378 CTR: c000000000a3c820
	REGS: c[PII_REDACTED]e37e0 TRAP: 0300   Not tainted  (5.16.0-rc5-autotest-g6441998e2e37)
	MSR:  [PII_REDACTED] <SF,EE,ME,IR,DR,RI,LE>  CR: 28248484  XER: 00000004
	CFAR: c[PII_REDACTED]bdd24 DAR: [PII_REDACTED] DSISR: 40000000 IRQMASK: 0
	GPR00: c[PII_REDACTED]b55d0 c[PII_REDACTED]e3a80 c[PII_REDACTED]f0200 [PII_REDACTED]
	...
	NIP [c000000000a3c840] napi_enable+0x20/0xc0
	LR [c[PII_REDACTED]b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
	Call Trace:
	[c[PII_REDACTED]e3a80] [[PII_REDACTED]] 0x6 (unreliable)
	[c[PII_REDACTED]e3ab0] [c[PII_REDACTED]b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
	[c[PII_REDACTED]e3b40] [c[PII_REDACTED]bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
	[c[PII_REDACTED]e3c60] [c[PII_REDACTED]76228] process_one_work+0x288/0x570
	[c[PII_REDACTED]e3d00] [c[PII_REDACTED]76588] worker_thread+0x78/0x660
	[c[PII_REDACTED]e3da0] [c[PII_REDACTED]822f0] kthread+0x1c0/0x1d0
	[c[PII_REDACTED]e3e10] [c[PII_REDACTED]0cf64] ret_from_kernel_thread+0x5c/0x64
	Instruction dump:
	7d2948f8 792307e0 4e[PII_REDACTED]0000 3c4c01eb 384239e0 f821ffd1 39430010
	38a0fff6 e92d1100 f9[PII_REDACTED]0000 <e9030010> f9[PII_REDACTED]0000 e9210020
	---[ end trace 5f8033b08fd27706 ]---
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/61772b0908c640d0309c40f7d41d062ca4e979fa; https://git.kernel.org/stable/c/960dfaf3b578dd23af012590e809ae2d58ba1827; https://git.kernel.org/stable/c/e08cb9056fb2564d1f6bad789bdf79ab09bf2f81
CVE: CVE-2022-48812
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: lantiq_gswip: don't use devres for mdiobus

As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")

mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.

The GSWIP switch is a platform device, so the initial set of constraints
that I thought would cause this (I2C or SPI buses which call ->remove on
->shutdown) do not apply. But there is one more which applies here.

If the DSA master itself is on a bus that calls ->remove from ->shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the GSWIP switch driver on shutdown.

So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.

The gswip driver has the code structure in place for orderly mdiobus
removal, so just replace devm_mdiobus_alloc() with the non-devres
variant, and add manual free where necessary, to ensure that we don't
let devres free a still-registered bus.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0d120dfb5d67edc5bcd1804e167dba2b30809afd; https://git.kernel.org/stable/c/2443ba2fe396bdde187a2fdfa6a57375643ae93c; https://git.kernel.org/stable/c/b5652bc50dde7b84e93dfb25479b64b817e377c1
CVE: CVE-2022-48813
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: felix: don't use devres for mdiobus

As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")

mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.

The Felix VSC9959 switch is a PCI device, so the initial set of
constraints that I thought would cause this (I2C or SPI buses which call
->remove on ->shutdown) do not apply. But there is one more which
applies here.

If the DSA master itself is on a bus that calls ->remove from ->shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the felix switch driver on shutdown.

So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.

The felix driver has the code structure in place for orderly mdiobus
removal, so just replace devm_mdiobus_alloc_size() with the non-devres
variant, and add manual free where necessary, to ensure that we don't
let devres free a still-registered bus.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/209bdb7ec6a28c7cdf580a0a98afbc9fc3b98932; https://git.kernel.org/stable/c/8cda7577a0b4018572f31e0caadfabd305ea2786; https://git.kernel.org/stable/c/95e5402f9430b3c7d885dd3ec4c8c02c17936923
CVE: CVE-2022-48814
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: seville: register the mdiobus under devres

As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")

mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.

The Seville VSC9959 switch is a platform device, so the initial set of
constraints that I thought would cause this (I2C or SPI buses which call
->remove on ->shutdown) do not apply. But there is one more which
applies here.

If the DSA master itself is on a bus that calls ->remove from ->shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the seville switch driver on shutdown.

So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.

The seville driver has a code structure that could accommodate both the
mdiobus_unregister and mdiobus_free calls, but it has an external
dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls
devm_mdiobus_alloc_size() on its behalf. So rather than restructuring
that, and exporting yet one more symbol mscc_miim_teardown(), let's work
with devres and replace of_mdiobus_register with the devres variant.
When we use all-devres, we can ensure that devres doesn't free a
still-registered bus (it either runs both callbacks, or none).
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0e816362d823cd46c666e64d8bffe329ee22f4cc; https://git.kernel.org/stable/c/1d13e[PII_REDACTED]c62800c9d3d99b4ed570e27e7; https://git.kernel.org/stable/c/bd488afc3b39e045ba71aab472233f2a78726e7b
CVE: CVE-2022-48815
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: bcm_sf2: don't use devres for mdiobus

As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")

mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.

The Starfighter 2 is a platform device, so the initial set of
constraints that I thought would cause this (I2C or SPI buses which call
->remove on ->shutdown) do not apply. But there is one more which
applies here.

If the DSA master itself is on a bus that calls ->remove from ->shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the bcm_sf2 switch driver on shutdown.

So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.

The bcm_sf2 driver has the code structure in place for orderly mdiobus
removal, so just replace devm_mdiobus_alloc() with the non-devres
variant, and add manual free where necessary, to ensure that we don't
let devres free a still-registered bus.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/08e1a3554e99a1a5bd[PII_REDACTED]e2383ee85cae; https://git.kernel.org/stable/c/08f1a[PII_REDACTED]4bb9cc1b153ecb516e9f2889d; https://git.kernel.org/stable/c/2770b795294ed312375c11ef1d0b810499c66b83
CVE: CVE-2022-48816
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: lock against ->sock changing during sysfs read

->sock can be set to NULL asynchronously unless ->recv_mutex is held.
So it is important to hold that mutex.  Otherwise a sysfs read can
trigger an oops.
Commit 17f09d3f619a ("SUNRPC: Check if the xprt is connected before
handling sysfs reads") appears to attempt to fix this problem, but it
only narrows the race window.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/9482ab4540f5bcc869b44c067ae99b5fca16bd07; https://git.kernel.org/stable/c/b49ea673e119f59c71645e2f65b3ccad857c90ee; https://git.kernel.org/stable/c/9482ab4540f5bcc869b44c067ae99b5fca16bd07
CVE: CVE-2022-48817
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: ar9331: register the mdiobus under devres

As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")

mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.

The ar9331 is an MDIO device, so the initial set of constraints that I
thought would cause this (I2C or SPI buses which call ->remove on
->shutdown) do not apply. But there is one more which applies here.

If the DSA master itself is on a bus that calls ->remove from ->shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the ar9331 switch driver on shutdown.

So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.

The ar9331 driver doesn't have a complex code structure for mdiobus
removal, so just replace of_mdiobus_register with the devres variant in
order to be all-devres and ensure that we don't free a still-registered
bus.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/475ce5dcf2d88fd4f3c213a0ac944e3e40702970; https://git.kernel.org/stable/c/50facd86e9fbc4b93fe02e5fe05776047f45dbfb; https://git.kernel.org/stable/c/aae1c6a1d3d696fc33b609fb12fe744a556d1dc5
CVE: CVE-2022-48818
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: mv88e6xxx: don't use devres for mdiobus

As explained in commits:
74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")
5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")

mdiobus_free() will panic when called from devm_mdiobus_free() <-
devres_release_all() <- __device_release_driver(), and that mdiobus was
not previously unregistered.

The mv88e6xxx is an MDIO device, so the initial set of constraints that
I thought would cause this (I2C or SPI buses which call ->remove on
->shutdown) do not apply. But there is one more which applies here.

If the DSA master itself is on a bus that calls ->remove from ->shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the Marvell switch driver on shutdown.

systemd-shutdown[1]: Powering off.
mv88e6085 0x[PII_REDACTED]b96000:00 sw_gl0: Link is Down
fsl-mc dpbp.9: Removing from iommu group 7
fsl-mc dpbp.8: Removing from iommu group 7
------------[ cut here ]------------
kernel BUG at drivers/net/phy/mdio_bus.c:677!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15
pc : mdiobus_free+0x44/0x50
lr : devm_mdiobus_free+0x10/0x20
Call trace:
 mdiobus_free+0x44/0x50
 devm_mdiobus_free+0x10/0x20
 devres_release_all+0xa0/0x100
 __device_release_driver+0x190/0x220
 device_release_driver_internal+0xac/0xb0
 device_links_unbind_consumers+0xd4/0x100
 __device_release_driver+0x4c/0x220
 device_release_driver_internal+0xac/0xb0
 device_links_unbind_consumers+0xd4/0x100
 __device_release_driver+0x94/0x220
 device_release_driver+0x28/0x40
 bus_remove_device+0x118/0x124
 device_del+0x174/0x420
 fsl_mc_device_remove+0x24/0x40
 __fsl_mc_device_remove+0xc/0x20
 device_for_each_child+0x58/0xa0
 dprc_remove+0x90/0xb0
 fsl_mc_driver_remove+0x20/0x5c
 __device_release_driver+0x21c/0x220
 device_release_driver+0x28/0x40
 bus_remove_device+0x118/0x124
 device_del+0x174/0x420
 fsl_mc_bus_remove+0x80/0x100
 fsl_mc_bus_shutdown+0xc/0x1c
 platform_shutdown+0x20/0x30
 device_shutdown+0x154/0x330
 kernel_power_off+0x34/0x6c
 __do_sys_reboot+0x15c/0x250
 __arm64_sys_reboot+0x20/0x30
 invoke_syscall.constprop.0+0x4c/0xe0
 do_el0_svc+0x4c/0x150
 el0_svc+0x24/0xb0
 el0t_64_sync_handler+0xa8/0xb0
 el0t_64_sync+0x178/0x17c

So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.

The Marvell driver already has a good structure for mdiobus removal, so
just plug in mdiobus_free and get rid of devres.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1b451c3994a2d322f8e55032c62c8b47b7d95900; https://git.kernel.org/stable/c/8b626d45127d6f5ada7d815b83cfdc09e8cb1394; https://git.kernel.org/stable/c/8ccebe77df6e0d88c72ba5e69cf1835927e53b6c
CVE: CVE-2022-48819
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case

syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY)
calls over the same TCP socket would again trigger the
infamous warning in inet_sock_destruct()

	WARN_ON(sk_forward_alloc_get(sk));

While Talal took into account a mix of regular copied data
and MSG_ZEROCOPY one in the same skb, the sendpage() path
has been forgotten.

We want the charging to happen for sendpage(), because
pages could be coming from a pipe. What is missing is the
downgrading of pure zerocopy status to make sure
sk_forward_alloc will stay synced.

Add tcp_downgrade_zcopy_pure() helper so that we can
use it from the two callers.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/47f3860c4931175f112f28dcac66eacca9b1040f; https://git.kernel.org/stable/c/f8d9d938514f46c4892aff6bfe32f425e84d81cc; https://git.kernel.org/stable/c/47f3860c4931175f112f28dcac66eacca9b1040f
CVE: CVE-2022-48820
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable()

This error path needs to decrement "usbphyc->n_pll_cons.counter" before
returning.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/0ad1a88fa3eb0ded7798f52b79bc33f75fc9a6d2; https://git.kernel.org/stable/c/94b16ca86ab688ed6fad4548f70137f93cf1f0a9; https://git.kernel.org/stable/c/cfc826c88a79e22ba5d8001556eb2c7efd8a01b6
CVE: CVE-2022-48821
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

misc: fastrpc: avoid double fput() on failed usercopy

If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF
ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact,
dma_buf_fd() called fd_install() before, i.e. "consumed" one reference,
leaving us with none.

Calling dma_buf_put() will therefore put a reference we no longer own,
leading to a valid file descritor table entry for an already released
'file' object which is a straight use-after-free.

Simply avoid calling dma_buf_put() and rely on the process exit code to
do the necessary cleanup, if needed, i.e. if the file descriptor is
still valid.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/46963e2e0629cb31c96b1d47ddd89dc3d8990b34; https://git.kernel.org/stable/c/4e6fd2b5fcf8e7119305a6042bd92e7f2b9ed215; https://git.kernel.org/stable/c/76f85c307ef9f10aa2cef1b1d5ee654c1f3345fc
CVE: CVE-2022-48822
Published: 2024-07-16
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: f_fs: Fix use-after-free for epfile

Consider a case where ffs_func_eps_disable is called from
ffs_func_disable as part of composition switch and at the
same time ffs_epfile_release get called from userspace.
ffs_epfile_release will free up the read buffer and call
ffs_data_closed which in turn destroys ffs->epfiles and
mark it as NULL. While this was happening the driver has
already initialized the local epfile in ffs_func_eps_disable
which is now freed and waiting to acquire the spinlock. Once
spinlock is acquired the driver proceeds with the stale value
of epfile and tries to free the already freed read buffer
causing use-after-free.

Following is the illustration of the race:

      CPU1                                  CPU2

   ffs_func_eps_disable
   epfiles (local copy)
					ffs_epfile_release
					ffs_data_closed
					if (last file closed)
					ffs_data_reset
					ffs_data_clear
					ffs_epfiles_destroy
spin_lock
dereference epfiles

Fix this races by taking epfiles local copy & assigning it under
spinlock and if epfiles(local) is null then update it in ffs->epfiles
then finally destroy it.
Extending the scope further from the race, protecting the ep related
structures, and concurrent accesses.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0042178a69eb77a979e36a50dcce9794a3140ef8; https://git.kernel.org/stable/c/32048f4be071f9a[PII_REDACTED]f1786f45bb22dc2; https://git.kernel.org/stable/c/3e078b[PII_REDACTED]301d946297bafd69294ad2c