vdanen/rhvex-cve huggingface dataset:
CVE-2025-38056 (Moderate severity, published 2025-06-17)
CVSS score: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: Intel: hda: Fix UAF when reloading module

hda_generic_machine_select() appends -idisp to the tplg filename by
allocating a new string with devm_kasprintf(), then stores the string
right back into the global variable snd_soc_acpi_intel_hda_machines.
When the module is unloaded, this memory is freed, resulting in a global
variable pointing to freed memory.  Reloading the module then triggers
a use-after-free:

BUG: KFENCE: use-after-free read in string+0x48/0xe0

Use-after-free read at 0x00000000967e0109 (in kfence-#99):
 string+0x48/0xe0
 vsnprintf+0x329/0x6e0
 devm_kvasprintf+0x54/0xb0
 devm_kasprintf+0x58/0x80
 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic]
 sof_probe_work+0x7f/0x600 [snd_sof]
 process_one_work+0x17b/0x330
 worker_thread+0x2ce/0x3f0
 kthread+0xcf/0x100
 ret_from_fork+0x31/0x50
 ret_from_fork_asm+0x1a/0x30

kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64

allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago):
 devm_kmalloc+0x52/0x120
 devm_kvasprintf+0x66/0xb0
 devm_kasprintf+0x58/0x80
 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic]
 sof_probe_work+0x7f/0x600 [snd_sof]
 process_one_work+0x17b/0x330
 worker_thread+0x2ce/0x3f0
 kthread+0xcf/0x100
 ret_from_fork+0x31/0x50
 ret_from_fork_asm+0x1a/0x30

freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago):
 release_nodes+0x43/0xb0
 devres_release_all+0x90/0xf0
 device_unbind_cleanup+0xe/0x70
 device_release_driver_internal+0x1c1/0x200
 driver_detach+0x48/0x90
 bus_remove_driver+0x6d/0xf0
 pci_unregister_driver+0x42/0xb0
 __do_sys_delete_module+0x1d1/0x310
 do_syscall_64+0x82/0x190
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Fix it by copying the match array with devm_kmemdup_array() before we
modify it.
CVE-2025-32908 (Important severity, published 2025-04-13)
CVSS score: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-115
Description: A flaw was found in libsoup. The HTTP/2 server in libsoup may not fully validate the values of pseudo-headers :scheme, :authority, and :path, which may allow a user to cause a denial of service (DoS).
Mitigation: Currently, no mitigation was found for this vulnerability.
CVE-2025-27209 (Moderate severity, published 2025-07-18)
CVSS score: 5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)
CWE: CWE-400
Description: A flaw was found in nodejs. The V8 component’s rapidhash implementation introduces a HashDoS vulnerability, allowing an attacker who can control the strings being hashed to trigger excessive CPU usage by generating numerous hash collisions. This exploitation vector results in an application level denial of service condition due to resource exhaustion.
Statement: The severity of this vulnerability is rated Moderate, as it does not impact system availability. The effects are confined to the application layer, without compromising the underlying system stability.

No Red Hat products or offerings are affected by this vulnerability.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-24976 (Moderate severity, published 2025-02-11)
CVSS score: 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N)
CWE: CWE-639
Description: A flaw was found in Distribution. Certain versions with token authentication enabled may be vulnerable to an issue where token authentication allows an attacker to inject an untrusted signing key in a JSON web token (JWT). The issue is due to how the JSON web key (JWK) verification is performed. When a JWT contains a JWK header without a certificate chain, the code only checks if the KeyID (`kid`) matches one of the trusted keys but doesn't verify that the key material matches.
Statement: Within regulated environments, a combination of the following controls acts as a significant barrier to successful exploitation of a CWE-639: Authorization Bypass Through User-Controlled Key vulnerability and therefore downgrades the severity of this particular CVE from Moderate to Low.

Access controls strictly enforce user-to-resource authorization, preventing manipulation of identifiers such as namespace names or resource paths to gain unauthorized access. Least privilege principles restrict access to only the resources necessary for each role, reducing the potential impact of any misused identifiers. Account management enforces unique user identities and session controls to prevent horizontal or vertical privilege escalation. Remote access is tightly governed through hardened authentication mechanisms and session limitations, further minimizing the risk of user-controlled access vectors. Additionally, access enforcement policies are applied consistently across services and verified through routine validation, reducing the likelihood of authorization bypass conditions.
CVE-2025-21762 (Moderate severity, published 2025-02-26)
CVSS score: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
CWE: CWE-416
Description: In the Linux kernel, the following vulnerability has been resolved:

arp: use RCU protection in arp_xmit()

arp_xmit() can be called without RTNL or RCU protection.

Use RCU protection to avoid potential UAF.
CVE-2025-1931 (Important severity, published 2025-03-04)
CVSS score: 7.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H)
CWE: CWE-416
Description: It was possible to cause a use-after-free in the content process side of a WebTransport connection, leading to a potentially exploitable crash. This vulnerability affects Firefox < 136, Firefox ESR < 115.21, Firefox ESR < 128.8, Thunderbird < 136, and Thunderbird < 128.8.
Statement: Red Hat Product Security rates the severity of this flaw as determined by the Mozilla Foundation Security Advisory.
CVE-2025-38113 (Moderate severity, published 2025-07-02)
CVSS score: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: CPPC: Fix NULL pointer dereference when nosmp is used

With nosmp in cmdline, other CPUs are not brought up, leaving
their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu()
dereferences these NULL pointers, causing panic.

Panic backtrace:

[    0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8
...
[    0.403255] [<ffffffff809a5818>] cppc_allow_fast_switch+0x6a/0xd4
...
Kernel panic - not syncing: Attempted to kill init!

[ rjw: New subject ]
CVE-2025-21918 (Low severity, published 2025-03-31)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: Fix NULL pointer access

Resources should be released only after all threads that utilize them
have been destroyed.
This commit ensures that resources are not released prematurely by waiting
for the associated workqueue to complete before deallocating them.
CVE-2025-37966 (Low severity, published 2025-05-19)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL

When userspace does PR_SET_TAGGED_ADDR_CTRL, but Supm extension is not
available, the kernel crashes:

Oops - illegal instruction [#1]
    [snip]
epc : set_tagged_addr_ctrl+0x112/0x15a
 ra : set_tagged_addr_ctrl+0x74/0x15a
epc : ffffffff80011ace ra : ffffffff80011a30 sp : ffffffc60039be10
    [snip]
status: 0000000200000120 badaddr: 0000000010a79073 cause: 0000000000000002
    set_tagged_addr_ctrl+0x112/0x15a
    __riscv_sys_prctl+0x352/0x73c
    do_trap_ecall_u+0x17c/0x20c
    andle_exception+0x150/0x15c

Fix it by checking if Supm is available.
CVE-2025-7365 (Moderate severity, published 2025-06-19)
CVSS score: 5.4 (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N)
CWE: CWE-346
Description: A flaw was found in Keycloak. When an authenticated attacker attempts to merge accounts with another existing account during an identity provider (IdP) login, the attacker will subsequently be prompted to "review profile" information. This vulnerability allows the attacker to modify their email address to match that of a victim's account, triggering a verification email sent to the victim's email address. The attacker's email address is not present in the verification email content, making it a potential phishing opportunity. If the victim clicks the verification link, the attacker can gain access to the victim's account.
Statement: To exploit this vulnerability, IdP must be configured in Keycloak and the attacker would require both a registered Keycloak and identity provider account. Additionally, an attacker would need to know the email or Keycloak username of the victim. Finally, the victim would need to accept the verification link within the 5 minutes that the token is active.
Mitigation: Disable account review in the Identity Provider to prevent users from potentially modifying identity information. Disable the email verification step and use only re-authentication step.
CVE-2025-38390 (Moderate severity, published 2025-07-24)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: No description is available for this CVE.
CVE-2025-3263 (Moderate severity, published 2025-07-07)
CVSS score: 5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)
CWE: CWE-1333
Description: A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library. This vulnerability may allow an attacker to induce a denial of service in the application using the Transformers library.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-37989 (Moderate severity, published 2025-05-19)
CVSS score: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

net: phy: leds: fix memory leak

A network restart test on a router led to an out-of-memory condition,
which was traced to a memory leak in the PHY LED trigger code.

The root cause is misuse of the devm API. The registration function
(phy_led_triggers_register) is called from phy_attach_direct, not
phy_probe, and the unregister function (phy_led_triggers_unregister)
is called from phy_detach, not phy_remove. This means the register and
unregister functions can be called multiple times for the same PHY
device, but devm-allocated memory is not freed until the driver is
unbound.

This also prevents kmemleak from detecting the leak, as the devm API
internally stores the allocated pointer.

Fix this by replacing devm_kzalloc/devm_kcalloc with standard
kzalloc/kcalloc, and add the corresponding kfree calls in the unregister
path.
CVE-2025-6431 (Low severity, published 2025-06-24)
CVSS score: 3.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N)
Description: When a link can be opened in an external application, Firefox for Android will, by default, prompt the user before doing so. An attacker could have bypassed this prompt, potentially exposing the user to security vulnerabilities or privacy leaks in external applications. 
*This bug only affects Firefox for Android. Other versions of Firefox are unaffected.* This vulnerability affects Firefox < 140.
Statement: Red Hat Product Security rates the severity of this flaw as determined by the Mozilla Foundation Security Advisory.
CVE-2025-37823 (Moderate severity, published 2025-05-07)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too

Similarly to the previous patch, we need to safe guard hfsc_dequeue()
too. But for this one, we don't have a reliable reproducer.
CVE-2025-38451 (Moderate severity, published 2025-07-24)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: No description is available for this CVE.
CVE-2025-21670 (Moderate severity, published 2025-01-30)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: In the Linux kernel, the following vulnerability has been resolved:

vsock/bpf: return early if transport is not assigned

Some of the core functions can only be called if the transport
has been assigned.

As Michal reported, a socket might have the transport at NULL,
for example after a failed connect(), causing the following trace:

    BUG: kernel NULL pointer dereference, address: 00000000000000a0
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 0
    Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 15 UID: 0 PID: 1198 Comm: a.out Not tainted 6.13.0-rc2+
    RIP: 0010:vsock_connectible_has_data+0x1f/0x40
    Call Trace:
     vsock_bpf_recvmsg+0xca/0x5e0
     sock_recvmsg+0xb9/0xc0
     __sys_recvfrom+0xb3/0x130
     __x64_sys_recvfrom+0x20/0x30
     do_syscall_64+0x93/0x180
     entry_SYSCALL_64_after_hwframe+0x76/0x7e

So we need to check the `vsk->transport` in vsock_bpf_recvmsg(),
especially for connected sockets (stream/seqpacket) as we already
do in __vsock_connectible_recvmsg().
CVE-2025-38144 (Moderate severity, published 2025-07-02)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

watchdog: lenovo_se30_wdt: Fix possible devm_ioremap() NULL pointer dereference in lenovo_se30_wdt_probe()

devm_ioremap() returns NULL on error. Currently, lenovo_se30_wdt_probe()
does not check for this case, which results in a NULL pointer
dereference.

Add NULL check after devm_ioremap() to prevent this issue.
CVE-2025-21735 (Important severity, published 2025-02-26)
CVSS score: 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-787
Description: In the Linux kernel, the following vulnerability has been resolved:

NFC: nci: Add bounds checking in nci_hci_create_pipe()

The "pipe" variable is a u8 which comes from the network.  If it's more
than 127, then it results in memory corruption in the caller,
nci_hci_connect_gate().
CVE-2025-39755 (Moderate severity, published 2025-04-17)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: gpib: Fix cb7210 pcmcia Oops

The  pcmcia_driver struct was still only using the old .name
initialization in the drv field. This led to a NULL pointer
deref Oops in strcmp called from pcmcia_register_driver.

Initialize the pcmcia_driver struct name field.
CVE-2025-22119 (Low severity, published 2025-04-15)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: init wiphy_work before allocating rfkill fails

syzbort reported a uninitialize wiphy_work_lock in cfg80211_dev_free. [1]

After rfkill allocation fails, the wiphy release process will be performed,
which will cause cfg80211_dev_free to access the uninitialized wiphy_work
related data.

Move the initialization of wiphy_work to before rfkill initialization to
avoid this issue.

[1]
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 UID: 0 PID: 5935 Comm: syz-executor550 Not tainted 6.14.0-rc6-syzkaller-00103-g4003c9e78778 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 assign_lock_key kernel/locking/lockdep.c:983 [inline]
 register_lock_class+0xc39/0x1240 kernel/locking/lockdep.c:1297
 __lock_acquire+0x135/0x3c40 kernel/locking/lockdep.c:5103
 lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5851
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x3a/0x60 kernel/locking/spinlock.c:162
 cfg80211_dev_free+0x30/0x3d0 net/wireless/core.c:1196
 device_release+0xa1/0x240 drivers/base/core.c:2568
 kobject_cleanup lib/kobject.c:689 [inline]
 kobject_release lib/kobject.c:720 [inline]
 kref_put include/linux/kref.h:65 [inline]
 kobject_put+0x1e4/0x5a0 lib/kobject.c:737
 put_device+0x1f/0x30 drivers/base/core.c:3774
 wiphy_free net/wireless/core.c:1224 [inline]
 wiphy_new_nm+0x1c1f/0x2160 net/wireless/core.c:562
 ieee80211_alloc_hw_nm+0x1b7a/0x2260 net/mac80211/main.c:835
 mac80211_hwsim_new_radio+0x1d6/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5185
 hwsim_new_radio_nl+0xb42/0x12b0 drivers/net/wireless/virtual/mac80211_hwsim.c:6242
 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115
 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
 genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210
 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2533
 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219
 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
 netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1338
 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1882
 sock_sendmsg_nosec net/socket.c:718 [inline]
 __sock_sendmsg net/socket.c:733 [inline]
 ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2573
 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2627
 __sys_sendmsg+0x16e/0x220 net/socket.c:2659
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83

Close: https://syzkaller.appspot.com/bug?extid=aaf0488c83d1d5f4f029
CVE-2025-49007 (Important severity, published 2025-06-04)
CVSS score: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-770
Description: A flaw was found in Rack. The Content-Disposition parsing component exhibits a denial of service vulnerability due to improper handling of specially crafted input, allowing a remote attacker to trigger a crash. This vulnerability is triggered by processing a malicious Content-Disposition header. Consequently, a remote attacker can cause the Rack web server interface to become unavailable.
Statement: This vulnerability in Rack is considered Important rather than Moderate due to its impact on core request handling and application availability. The flaw lies in the inefficient parsing of the Content-Disposition header, commonly used in multipart form submissions. An attacker can exploit this by sending specially crafted input that causes the parser to consume excessive CPU resources, leading to a denial-of-service (DoS) condition. Since virtually all Rails applications and many other Ruby web apps rely on Rack for multipart parsing, the attack surface is widespread and affects production systems at the framework level. The attack does not require authentication and can be triggered with a single malicious request, making it low-cost but high-impact. Furthermore, because the vulnerability is exploited during early request processing, it can bypass typical application-level protections. This combination of broad exposure, low complexity, and high disruption potential elevates the severity to important.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-26623 (Moderate severity, published 2025-02-18)
CVSS score: 6.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L)
CWE: CWE-416
Description: A heap overflow vulnerability was found in the Exiv2 library. In affected versions, the issue is triggered when Exiv2 is used to write metadata into a crafted image file. This could allow an attacker to execute code if they can trick the victim into running Exiv2 on a crafted image file. Note that this bug is only triggered when writing the metadata, which is a less frequently used Exiv2 operation than reading the metadata.
CVE-2025-53689 (Important severity, published 2025-07-14)
CVSS score: 7.1 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L)
CWE: CWE-611
Description: An XML external entity flaw was found in Apache Jackrabbit. This issue occurs when using an unsecured document builder to load privileges and is vulnerable to an attack where a malicious user can inject harmful code.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-37931 (Low severity, published 2025-05-19)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: adjust subpage bit start based on sectorsize

When running machines with 64k page size and a 16k nodesize we started
seeing tree log corruption in production.  This turned out to be because
we were not writing out dirty blocks sometimes, so this in fact affects
all metadata writes.

When writing out a subpage EB we scan the subpage bitmap for a dirty
range.  If the range isn't dirty we do

	bit_start++;

to move onto the next bit.  The problem is the bitmap is based on the
number of sectors that an EB has.  So in this case, we have a 64k
pagesize, 16k nodesize, but a 4k sectorsize.  This means our bitmap is 4
bits for every node.  With a 64k page size we end up with 4 nodes per
page.

To make this easier this is how everything looks

[0         16k       32k       48k     ] logical address
[0         4         8         12      ] radix tree offset
[               64k page               ] folio
[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers
[ | | | |  | | | |   | | | |   | | | | ] bitmap

Now we use all of our addressing based on fs_info->sectorsize_bits, so
as you can see the above our 16k eb->start turns into radix entry 4.

When we find a dirty range for our eb, we correctly do bit_start +=
sectors_per_node, because if we start at bit 0, the next bit for the
next eb is 4, to correspond to eb->start 16k.

However if our range is clean, we will do bit_start++, which will now
put us offset from our radix tree entries.

In our case, assume that the first time we check the bitmap the block is
not dirty, we increment bit_start so now it == 1, and then we loop
around and check again.  This time it is dirty, and we go to find that
start using the following equation

	start = folio_start + bit_start * fs_info->sectorsize;

so in the case above, eb->start 0 is now dirty, and we calculate start
as

	0 + 1 * fs_info->sectorsize = 4096
	4096 >> 12 = 1

Now we're looking up the radix tree for 1, and we won't find an eb.
What's worse is now we're using bit_start == 1, so we do bit_start +=
sectors_per_node, which is now 5.  If that eb is dirty we will run into
the same thing, we will look at an offset that is not populated in the
radix tree, and now we're skipping the writeout of dirty extent buffers.

The best fix for this is to not use sectorsize_bits to address nodes,
but that's a larger change.  Since this is a fs corruption problem fix
it simply by always using sectors_per_node to increment the start bit.