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

wifi: ath12k: fix possible out-of-bound read in ath12k_htt_pull_ppdu_stats()

len is extracted from HTT message and could be an unexpected value in
case errors happen, so add validation before using to avoid possible
out-of-bound read in the following message iteration and parsing.

The same issue also applies to ppdu_info->ppdu_stats.common.num_users,
so validate it before using too.

These are found during code review.

Compile test only.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/1bc44a505a229bb1dd4957e11aa594edeea3690e; https://git.kernel.org/stable/c/79527c21a3ce04cffc35ea54f74ee087e532be57; https://git.kernel.org/stable/c/c9e44111da221246efb2e623ae1be40a5cf6542c
CVE: CVE-2023-52828
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Detect IP == ksym.end as part of BPF program

Now that bpf_throw kfunc is the first such call instruction that has
noreturn semantics within the verifier, this also kicks in dead code
elimination in unprecedented ways. For one, any instruction following
a bpf_throw call will never be marked as seen. Moreover, if a callchain
ends up throwing, any instructions after the call instruction to the
eventually throwing subprog in callers will also never be marked as
seen.

The tempting way to fix this would be to emit extra 'int3' instructions
which bump the jited_len of a program, and ensure that during runtime
when a program throws, we can discover its boundaries even if the call
instruction to bpf_throw (or to subprogs that always throw) is emitted
as the final instruction in the program.

An example of such a program would be this:

do_something():
	...
	r0 = 0
	exit

foo():
	r1 = 0
	call bpf_throw
	r0 = 0
	exit

bar(cond):
	if r1 != 0 goto pc+2
	call do_something
	exit
	call foo
	r0 = 0  // Never seen by verifier
	exit	//

main(ctx):
	r1 = ...
	call bar
	r0 = 0
	exit

Here, if we do end up throwing, the stacktrace would be the following:

bpf_throw
foo
bar
main

In bar, the final instruction emitted will be the call to foo, as such,
the return address will be the subsequent instruction (which the JIT
emits as int3 on x86). This will end up lying outside the jited_len of
the program, thus, when unwinding, we will fail to discover the return
address as belonging to any program and end up in a panic due to the
unreliable stack unwinding of BPF programs that we never expect.

To remedy this case, make bpf_prog_ksym_find treat IP == ksym.end as
part of the BPF program, so that is_bpf_text_address returns true when
such a case occurs, and we are able to unwind reliably when the final
instruction ends up being a call instruction.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/327b92e8cb527ae097961ffd1610c720481947f5; https://git.kernel.org/stable/c/6058e[PII_REDACTED]457729a00734969acc6fd1d18; https://git.kernel.org/stable/c/66d9111f3517f85ef2af0337ece02683ce0faf21
CVE: CVE-2023-52829
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix possible out-of-bound write in ath12k_wmi_ext_hal_reg_caps()

reg_cap.phy_id is extracted from WMI event and could be an unexpected value
in case some errors happen. As a result out-of-bound write may occur to
soc->hal_reg_cap. Fix it by validating reg_cap.phy_id before using it.

This is found during code review.

Compile tested only.
CVSS Score: 6.2 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/4dd0547e8b45faf6f95373be5436b66cde326c0e; https://git.kernel.org/stable/c/b302dce3d9edea5b93d1902a541684a967f3c63c; https://git.kernel.org/stable/c/dfe13eaab043130f90dd3d57c7d88577c04adc97
CVE: CVE-2023-52830
Published: 2024-05-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-52831
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

cpu/hotplug: Don't offline the last non-isolated CPU

If a system has isolated CPUs via the "isolcpus=" command line parameter,
then an attempt to offline the last housekeeping CPU will result in a
WARN_ON() when rebuilding the scheduler domains and a subsequent panic due
to and unhandled empty CPU mas in partition_sched_domains_locked().

cpuset_hotplug_workfn()
  rebuild_sched_domains_locked()
    ndoms = generate_sched_domains(&doms, &attr);
      cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));

Thus results in an empty CPU mask which triggers the warning and then the
subsequent crash:

WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408
Call trace:
 build_sched_domains+0x120c/0x1408
 partition_sched_domains_locked+0x234/0x880
 rebuild_sched_domains_locked+0x37c/0x798
 rebuild_sched_domains+0x30/0x58
 cpuset_hotplug_workfn+0x2a8/0x930

Unable to handle kernel paging request at virtual address fffe80027ab37080
 partition_sched_domains_locked+0x318/0x880
 rebuild_sched_domains_locked+0x37c/0x798

Aside of the resulting crash, it does not make any sense to offline the last
last housekeeping CPU.

Prevent this by masking out the non-housekeeping CPUs when selecting a
target CPU for initiating the CPU unplug operation via the work queue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/3073f6df783d9d75f7f69f73e16c7ef85d6cfb63; https://git.kernel.org/stable/c/335a47ed71e332c82339d1aec0c7f6caccfcda13; https://git.kernel.org/stable/c/3410b702354702b500bde10e3cc1f9db8731d908
CVE: CVE-2023-52832
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: don't return unset power in ieee80211_get_tx_power()

We can get a UBSAN warning if ieee80211_get_tx_power() returns the
INT_MIN value mac80211 internally uses for "unset power level".

 UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
 [PII_REDACTED] * 100 cannot be represented in type 'int'
 CPU: 0 PID: 20433 Comm: insmod Tainted: G        WC OE
 Call Trace:
  dump_stack+0x74/0x92
  ubsan_epilogue+0x9/0x50
  handle_overflow+0x8d/0xd0
  __ubsan_handle_mul_overflow+0xe/0x10
  nl80211_send_iface+0x688/0x6b0 [cfg80211]
  [...]
  cfg80211_register_wdev+0x78/0xb0 [cfg80211]
  cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]
  [...]
  ieee80211_if_add+0x60e/0x8f0 [mac80211]
  ieee80211_register_hw+0xda5/0x1170 [mac80211]

In this case, simply return an error instead, to indicate
that no data is available.
CVSS Score: 9.1 (CRITICAL)
CWE: CWE-920
References: https://git.kernel.org/stable/c/21a0f310a9f3bfd2b4cf4f382430e638607db846; https://git.kernel.org/stable/c/2be24c47ac19bf639c48c082486c08888bd603c6; https://git.kernel.org/stable/c/5a94cffe90e20e8fade0b9abd4370bd671fe87c7
CVE: CVE-2023-52833
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btusb: Add date->evt_skb is NULL check

fix crash because of null pointers

[ 6104.969662] BUG: kernel NULL pointer dereference, address:[PII_REDACTED]0000c8
[ 6104.969667] #PF: supervisor read access in kernel mode
[ 6104.969668] #PF: error_code(0x0000) - not-present page
[ 6104.969670] PGD 0 P4D 0
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
[ 6104.969689] RAX: [PII_REDACTED] RBX: ffff8ad560bb2000 RCX: [PII_REDACTED]
[ 6104.969691] RDX: [PII_REDACTED] RSI: ffffb8d681533d08 RDI: [PII_REDACTED]
[ 6104.969692] RBP: ffffb8d681533d70 R08: [PII_REDACTED] R09: [PII_REDACTED]
[ 6104.969694] R10: [PII_REDACTED] R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
[ 6104.969695] R13: [PII_REDACTED] R14: ffff8ad459618c18 R15: ffffb8d681533d90
[ 6104.969697] FS:  00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
[ 6104.969699] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[ 6104.969700] CR2:[PII_REDACTED]0000c8 CR3:[PII_REDACTED]20c001 CR4:[PII_REDACTED]760ef0
[ 6104.969701] PKRU: 55555554
[ 6104.969702] Call Trace:
[ 6104.969708]  btusb_mtk_shutdown+0x44/0x80 [btusb]
[ 6104.969732]  hci_dev_do_close+0x470/0x5c0 [bluetooth]
[ 6104.969748]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]
[ 6104.969753]  rfkill_set_block+0x92/0x160
[ 6104.969755]  rfkill_fop_write+0x136/0x1e0
[ 6104.969759]  __vfs_write+0x18/0x40
[ 6104.969761]  vfs_write+0xdf/0x1c0
[ 6104.969763]  ksys_write+0xb1/0xe0
[ 6104.969765]  __x64_sys_write+0x1a/0x20
[ 6104.969769]  do_syscall_64+0x51/0x180
[ 6104.969771]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: [PII_REDACTED]
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
[ 6104.969781] RDX: [PII_REDACTED] RSI: 00007ffeefe39060 RDI: [PII_REDACTED]
[ 6104.969782] RBP: 00007ffeefe39060 R08: [PII_REDACTED] R09: [PII_REDACTED]
[ 6104.969784] R10: 00007ffeefe38d97 R11: [PII_REDACTED] R12: [PII_REDACTED]
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0048ddf045bddc4dacb3e783fd869a2f8fb5be30; https://git.kernel.org/stable/c/13b1ebad4c175e6a9b0748acbf133c21a15d282a; https://git.kernel.org/stable/c/624820f7c8826dd010e8b1963303c145f99816e9
CVE: CVE-2023-52834
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

atl1c: Work around the DMA RX overflow issue

This is based on alx driver commit 881d0327db37 ("net: alx: Work around
the DMA RX overflow issue").

The alx and atl1c drivers had RX overflow error which was why a custom
allocator was created to avoid certain addresses. The simpler workaround
then created for alx driver, but not for atl1c due to lack of tester.

Instead of using a custom allocator, check the allocated skb address and
use skb_reserve() to move away from problematic 0x...fc0 address.

Tested on AR8131 on Acer 4540.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/32f08b7b430ee01ec47d730f961a3306c1c7b6fb; https://git.kernel.org/stable/c/54a6152da4993ec8e4b53dc3cf577f5a2c829afa; https://git.kernel.org/stable/c/57e44ff9c2c9747b2b1a53556810b0e5192655d6
CVE: CVE-2023-52835
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/core: Bail out early if the request AUX area is out of bound

When perf-record with a large AUX area, e.g 4GB, it fails with:

    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
    failed to mmap with 12 (Cannot allocate memory)

and it reveals a WARNING with __alloc_pages():

	------------[ cut here ]------------
	WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
	Call trace:
	 __alloc_pages+0x1ec/0x248
	 __kmalloc_large_node+0xc0/0x1f8
	 __kmalloc_node+0x134/0x1e8
	 rb_alloc_aux+0xe0/0x298
	 perf_mmap+0x440/0x660
	 mmap_region+0x308/0x8a8
	 do_mmap+0x3c0/0x528
	 vm_mmap_pgoff+0xf4/0x1b8
	 ksys_mmap_pgoff+0x18c/0x218
	 __arm64_sys_mmap+0x38/0x58
	 invoke_syscall+0x50/0x128
	 el0_svc_common.constprop.0+0x58/0x188
	 do_el0_svc+0x34/0x50
	 el0_svc+0x34/0x108
	 el0t_64_sync_handler+0xb8/0xc0
	 el0t_64_sync+0x1a4/0x1a8

'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to
maintains AUX trace pages. The allocated page for this array is physically
contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the
size of pointer array crosses the limitation set by MAX_ORDER, it reveals a
WARNING.

So bail out early with -ENOMEM if the request AUX area is out of bound,
e.g.:

    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
    failed to mmap with 12 (Cannot allocate memory)
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/1a2a4202c60fcdffbf04f259002ce9bff39edece; https://git.kernel.org/stable/c/2424410f94a94d91230ced094062d859714c984a; https://git.kernel.org/stable/c/2e905e608e38cf7f8dcddcf8a6036e91a78444cb
CVE: CVE-2023-52836
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

locking/ww_mutex/test: Fix potential workqueue corruption

In some cases running with the test-ww_mutex code, I was seeing
odd behavior where sometimes it seemed flush_workqueue was
returning before all the work threads were finished.

Often this would cause strange crashes as the mutexes would be
freed while they were being used.

Looking at the code, there is a lifetime problem as the
controlling thread that spawns the work allocates the
"struct stress" structures that are passed to the workqueue
threads. Then when the workqueue threads are finished,
they free the stress struct that was passed to them.

Unfortunately the workqueue work_struct node is in the stress
struct. Which means the work_struct is freed before the work
thread returns and while flush_workqueue is waiting.

It seems like a better idea to have the controlling thread
both allocate and free the stress structures, so that we can
be sure we don't corrupt the workqueue by freeing the structure
prematurely.

So this patch reworks the test to do so, and with this change
I no longer see the early flush_workqueue returns.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/304a2c4aad0fff887ce493e4197bf9cbaf394479; https://git.kernel.org/stable/c/9ed2d68b3925145f5f51c[PII_REDACTED]1d6082f75; https://git.kernel.org/stable/c/bccdd808902f8c677317cec47c306e42b93b849e
CVE: CVE-2023-52837
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

nbd: fix uaf in nbd_open

Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and
blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set
disk->private_data as NULL as before. UAF may be triggered in nbd_open()
if someone tries to open nbd device right after nbd_put() since nbd has
been free in nbd_dev_remove().

Fix this by implementing ->free_disk and free private data in it.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/327462725b0f759f093788dfbcb2f1fd132f956b; https://git.kernel.org/stable/c/4e9b3ec84dc[PII_REDACTED]1dad14e0a2300d6c2a3; https://git.kernel.org/stable/c/56bd7901b5e9dbc9112036ea615ebcba1565fafe
CVE: CVE-2023-52838
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: imsttfb: fix a resource leak in probe

I've re-written the error handling but the bug is that if init_imstt()
fails we need to call iounmap(par->cmap_regs).
CVSS Score: 6.2 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/18d26f9baca7d0d309303e3074a2252b8310884a; https://git.kernel.org/stable/c/382e1931e0c9cd58a5a8519cdc6cd9dc4d82b485; https://git.kernel.org/stable/c/6c66d737b2726ac7784269ddf32a31634f8f269d
CVE: CVE-2023-52840
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()

The put_device() calls rmi_release_function() which frees "fn" so the
dereference on the next line "fn->num_of_irqs" is a use after free.
Move the put_device() to the end to fix this.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2f236d8638f5b43e0c72919a6a27fe286c32053f; https://git.kernel.org/stable/c/303766bb92c5c225cf40f9bbbe7e29749406e2f2; https://git.kernel.org/stable/c/50d[PII_REDACTED]a14c6cd2b81c376e2dbeedbdff
CVE: CVE-2023-52841
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

media: vidtv: mux: Add check and kfree for kstrdup

Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.
Moreover, use kfree() in the later error handling in order to avoid
memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-476
References: https://git.kernel.org/stable/c/1fd6eb12642e0c32692924ff359c07de4b781d78; https://git.kernel.org/stable/c/64863ba8e6b7651d994c6e6d506cc8aa2ac45edb; https://git.kernel.org/stable/c/980be4c3b0d51c0f873fd[PII_REDACTED]61c66cf68
CVE: CVE-2023-52843
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

llc: verify mac len before reading mac header

LLC reads the mac header with eth_hdr without verifying that the skb
has an Ethernet header.

Syzbot was able to enter llc_rcv on a tun device. Tun can insert
packets without mac len and with user configurable skb->protocol
(passing a tun_pi header when not configuring IFF_NO_PI).

    BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
    BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
    llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
    llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
    llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
    __netif_receive_skb_one_core net/core/dev.c:5523 [inline]
    __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
    netif_receive_skb_internal net/core/dev.c:5723 [inline]
    netif_receive_skb+0x58/0x660 net/core/dev.c:5782
    tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
    tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002

Add a mac_len test before all three eth_hdr(skb) calls under net/llc.

There are further uses in include/net/llc_pdu.h. All these are
protected by a test skb->protocol == ETH_P_802_2. Which does not
protect against this tun scenario.

But the mac_len test added in this patch in llc_fixup_skb will
indirectly protect those too. That is called from llc_rcv before any
other LLC code.

It is tempting to just add a blanket mac_len check in llc_rcv, but
not sure whether that could break valid LLC paths that do not assume
an Ethernet header. 802.2 LLC may be used on top of non-802.3
protocols in principle. The below referenced commit shows that used
to, on top of Token Ring.

At least one of the three eth_hdr uses goes back to before the start
of git history. But the one that syzbot exercises is introduced in
this commit. That commit is old enough (2008), that effectively all
stable kernels should receive this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/0a720d0259ad3521ec6c9e4199f9f6fc75bac77a; https://git.kernel.org/stable/c/352887b3edd007cf9b0abc30fe9d98622acd859b; https://git.kernel.org/stable/c/3a2653828ffc6101aef80bf58d5b77484239f779
CVE: CVE-2023-52844
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

media: vidtv: psi: Add check for kstrdup

Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.
CVSS Score: 6.2 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3387490c89b10aeb4e71d78b65dbc9ba4b2385b9; https://git.kernel.org/stable/c/5c26aae3723965c291c65dd2ecad6a3240d422b0; https://git.kernel.org/stable/c/5cfcc8de7d733a1137b86954cc28ce99972311ad
CVE: CVE-2023-52846
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

hsr: Prevent use after free in prp_create_tagged_frame()

The prp_fill_rct() function can fail.  In that situation, it frees the
skb and returns NULL.  Meanwhile on the success path, it returns the
original skb.  So it's straight forward to fix bug by using the returned
value.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1787b9f0729d318d67cf7c5a95f0c3dba9a7cc18; https://git.kernel.org/stable/c/6086258bd5ea7b5c706ff62da42b8e271b2401db; https://git.kernel.org/stable/c/876f8ab52363f649bcc74072157dfd7adfbabc0d
CVE: CVE-2023-52847
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

media: bttv: fix use after free error due to btv->timeout timer

There may be some a race condition between timer function
bttv_irq_timeout and bttv_remove. The timer is setup in
probe and there is no timer_delete operation in remove
function. When it hit kfree btv, the function might still be
invoked, which will cause use after free bug.

This bug is found by static analysis, it may be false positive.

Fix it by adding del_timer_sync invoking to the remove function.

cpu0                cpu1
                  bttv_probe
                    ->timer_setup
                      ->bttv_set_dma
                        ->mod_timer;
bttv_remove
  ->kfree(btv);
                  ->bttv_irq_timeout
                    ->USE btv
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-416
References: https://git.kernel.org/stable/c/1871014d6ef4812ad11ef7d838d73ce09d632267; https://git.kernel.org/stable/c/20568d06f6069cb835e05eed432edf962645d226; https://git.kernel.org/stable/c/2f3d9198cdae1cb079ec8652f4defacd481eab2b
CVE: CVE-2023-52848
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to drop meta_inode's page cache in f2fs_put_super()

syzbot reports a kernel bug as below:

F2FS-fs (loop1): detect filesystem reference count leak during umount, type: 10, count: 1
kernel BUG at fs/f2fs/super.c:1639!
CPU: 0 PID: 15451 Comm: syz-executor.1 Not tainted 6.5.0-syzkaller-09338-ge0152e7481c6 #0
RIP: 0010:f2fs_put_super+0xce1/0xed0 fs/f2fs/super.c:1639
Call Trace:
 generic_shutdown_super+0x161/0x3c0 fs/super.c:693
 kill_block_super+0x3b/0x70 fs/super.c:1646
 kill_f2fs_super+0x2b7/0x3d0 fs/f2fs/super.c:4879
 deactivate_locked_super+0x9a/0x170 fs/super.c:481
 deactivate_super+0xde/0x100 fs/super.c:514
 cleanup_mnt+0x222/0x3d0 fs/namespace.c:1254
 task_work_run+0x14d/0x240 kernel/task_work.c:179
 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
 exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204
 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
 syscall_exit_to_user_mode+0x1d/0x60 kernel/entry/common.c:296
 do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

In f2fs_put_super(), it tries to do sanity check on dirty and IO
reference count of f2fs, once there is any reference count leak,
it will trigger panic.

The root case is, during f2fs_put_super(), if there is any IO error
in f2fs_wait_on_all_pages(), we missed to truncate meta_inode's page
cache later, result in panic, fix this case.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/10b2a6c0dade67b5a2b2d17fb75c457ea1985fad; https://git.kernel.org/stable/c/a4639380bbe66172df329f8b54aa7d2e943f0f64; https://git.kernel.org/stable/c/eb42e1862aa7934c2c21890097ce4993c5e0d192