xamxte/cve-to-cwe huggingface dataset:
CVE-2022-49682: In the Linux kernel, the following vulnerability has been resolved:  xtensa: Fix refcount leak bug in time.c  In calibrate_ccount(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
CVE-2022-49683: In the Linux kernel, the following vulnerability has been resolved:  iio: adc: adi-axi-adc: Fix refcount leak in adi_axi_adc_attach_client  of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2022-49684: In the Linux kernel, the following vulnerability has been resolved:  iio: adc: aspeed: Fix refcount leak in aspeed_adc_set_trim_data  of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
CVE-2022-49691: In the Linux kernel, the following vulnerability has been resolved:  erspan: do not assume transport header is always set  Rewrite tests in ip6erspan_tunnel_xmit() and erspan_fb_xmit() to not assume transport header is set.  syzbot reported:  WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline] WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963 Modules linked in: CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline] RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963 Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00 RSP: 0018:ffffc90005daf910 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000 RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003 RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40 R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000 FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0 Call Trace: <TASK> __netdev_start_xmit include/linux/netdevice.h:4805 [inline] netdev_start_xmit include/linux/netdevice.h:4819 [inline] xmit_one net/core/dev.c:3588 [inline] dev_hard_start_xmit+0x188/0x880 net/core/dev.c:3604 sch_direct_xmit+0x19f/0xbe0 net/sched/sch_generic.c:342 __dev_xmit_skb net/core/dev.c:3815 [inline] __dev_queue_xmit+0x14a1/0x3900 net/core/dev.c:4219 dev_queue_xmit include/linux/netdevice.h:2994 [inline] tx+0x6a/0xc0 drivers/block/aoe/aoenet.c:63 kthread+0x1e7/0x3b0 drivers/block/aoe/aoecmd.c:1229 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 </TASK>
CVE-2022-49693: In the Linux kernel, the following vulnerability has been resolved:  drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf  of_graph_get_remote_node() returns remote device node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.  Patchwork: https://patchwork.freedesktop.org/patch/488473/
CVE-2022-49704: In the Linux kernel, the following vulnerability has been resolved:  9p: fix fid refcount leak in v9fs_vfs_get_link  we check for protocol version later than required, after a fid has been obtained. Just move the version check earlier.
CVE-2022-49705: In the Linux kernel, the following vulnerability has been resolved:  9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl  We need to release directory fid if we fail halfway through open  This fixes fid leaking with xfstests generic 531
CVE-2022-49710: In the Linux kernel, the following vulnerability has been resolved:  dm mirror log: round up region bitmap size to BITS_PER_LONG  The code in dm-log rounds up bitset_size to 32 bits. It then uses find_next_zero_bit_le on the allocated region. find_next_zero_bit_le accesses the bitmap using unsigned long pointers. So, on 64-bit architectures, it may access 4 bytes beyond the allocated size.  Fix this bug by rounding up bitset_size to BITS_PER_LONG.  This bug was found by running the lvm2 testsuite with kasan.
CVE-2022-49712: In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe  of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL pointer.
CVE-2022-49714: In the Linux kernel, the following vulnerability has been resolved:  irqchip/realtek-rtl: Fix refcount leak in map_interrupts  of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function doesn't call of_node_put() in error path. Call of_node_put() directly after of_property_read_u32() to cover both normal path and error path.
CVE-2022-49715: In the Linux kernel, the following vulnerability has been resolved:  irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions  of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2022-49716: In the Linux kernel, the following vulnerability has been resolved:  irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions  of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. When kcalloc fails, it missing of_node_put() and results in refcount leak. Fix this by goto out_put_node label.
CVE-2022-49717: In the Linux kernel, the following vulnerability has been resolved:  irqchip/apple-aic: Fix refcount leak in build_fiq_affinity  of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2022-49718: In the Linux kernel, the following vulnerability has been resolved:  irqchip/apple-aic: Fix refcount leak in aic_of_ic_init  of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2022-49719: In the Linux kernel, the following vulnerability has been resolved:  irqchip/gic/realview: Fix refcount leak in realview_gic_of_init  of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2024-39441: In wifi display, there is a possible missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed.
CVE-2024-57985: In the Linux kernel, the following vulnerability has been resolved:  firmware: qcom: scm: Cleanup global '__scm' on probe failures  If SCM driver fails the probe, it should not leave global '__scm' variable assigned, because external users of this driver will assume the probe finished successfully.  For example TZMEM parts ('__scm->mempool') are initialized later in the probe, but users of it (__scm_smc_call()) rely on the '__scm' variable.  This fixes theoretical NULL pointer exception, triggered via introducing probe deferral in SCM driver with call trace:    qcom_tzmem_alloc+0x70/0x1ac (P)   qcom_tzmem_alloc+0x64/0x1ac (L)   qcom_scm_assign_mem+0x78/0x194   qcom_rmtfs_mem_probe+0x2d4/0x38c   platform_probe+0x68/0xc8
CVE-2024-57991: In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw89: chan: fix soft lockup in rtw89_entity_recalc_mgnt_roles()  During rtw89_entity_recalc_mgnt_roles(), there is a normalizing process which will re-order the list if an entry with target pattern is found. And once one is found, should have aborted the list_for_each_entry. But, `break` just aborted the inner for-loop. The outer list_for_each_entry still continues. Normally, only the first entry will match the target pattern, and the re-ordering will change nothing, so there won't be soft lockup. However, in some special cases, soft lockup would happen.  Fix it by `goto fill` to break from the list_for_each_entry.  The following is a sample of kernel log for this problem.  watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [wpa_supplicant:2055] [...] RIP: 0010:rtw89_entity_recalc ([...] chan.c:392 chan.c:479) rtw89_core [...]
CVE-2024-57992: In the Linux kernel, the following vulnerability has been resolved:  wifi: wilc1000: unregister wiphy only if it has been registered  There is a specific error path in probe functions in wilc drivers (both sdio and spi) which can lead to kernel panic, as this one for example when using SPI:  Unable to handle kernel paging request at virtual address 9f000000 when read [9f000000] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: wilc1000_spi(+) crc_itu_t crc7 wilc1000 cfg80211 bluetooth ecdh_generic ecc CPU: 0 UID: 0 PID: 106 Comm: modprobe Not tainted 6.13.0-rc3+ #22 Hardware name: Atmel SAMA5 PC is at wiphy_unregister+0x244/0xc40 [cfg80211] LR is at wiphy_unregister+0x1c0/0xc40 [cfg80211] [...]  wiphy_unregister [cfg80211] from wilc_netdev_cleanup+0x380/0x494 [wilc1000]  wilc_netdev_cleanup [wilc1000] from wilc_bus_probe+0x360/0x834 [wilc1000_spi]  wilc_bus_probe [wilc1000_spi] from spi_probe+0x15c/0x1d4  spi_probe from really_probe+0x270/0xb2c  really_probe from __driver_probe_device+0x1dc/0x4e8  __driver_probe_device from driver_probe_device+0x5c/0x140  driver_probe_device from __driver_attach+0x220/0x540  __driver_attach from bus_for_each_dev+0x13c/0x1a8  bus_for_each_dev from bus_add_driver+0x2a0/0x6a4  bus_add_driver from driver_register+0x27c/0x51c  driver_register from do_one_initcall+0xf8/0x564  do_one_initcall from do_init_module+0x2e4/0x82c  do_init_module from load_module+0x59a0/0x70c4  load_module from init_module_from_file+0x100/0x148  init_module_from_file from sys_finit_module+0x2fc/0x924  sys_finit_module from ret_fast_syscall+0x0/0x1c  The issue can easily be reproduced, for example by not wiring correctly a wilc device through SPI (and so, make it unresponsive to early SPI commands). It is due to a recent change decoupling wiphy allocation from wiphy registration, however wilc_netdev_cleanup has not been updated accordingly, letting it possibly call wiphy unregister on a wiphy which has never been registered.  Fix this crash by moving wiphy_unregister/wiphy_free out of wilc_netdev_cleanup, and by adjusting error paths in both drivers
CVE-2025-21708: In the Linux kernel, the following vulnerability has been resolved:  net: usb: rtl8150: enable basic endpoint checking  Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below.  For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary.  [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS:  00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>  rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733  __dev_open+0x2d4/0x4e0 net/core/dev.c:1474  __dev_change_flags+0x561/0x720 net/core/dev.c:8838  dev_change_flags+0x8f/0x160 net/core/dev.c:8910  devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177  inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003  sock_do_ioctl+0x116/0x280 net/socket.c:1222  sock_ioctl+0x22e/0x6c0 net/socket.c:1341  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl fs/ioctl.c:893 [inline]  __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ...  This change has not been tested on real hardware.
CVE-2025-21712: In the Linux kernel, the following vulnerability has been resolved:  md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime  After commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into struct md_bitmap_stats"), following panic is reported:  Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace:  <TASK>  md_seq_show+0x2d2/0x5b0  seq_read_iter+0x2b9/0x470  seq_read+0x12f/0x180  proc_reg_read+0x57/0xb0  vfs_read+0xf6/0x380  ksys_read+0x6c/0xf0  do_syscall_64+0x82/0x170  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger.  Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.
CVE-2025-21725: In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix oops due to unset link speed  It isn't guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always be set by the server, so the client must handle any values and then prevent oopses like below from happening:  Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48 89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8 e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 <48> f7 74 24 18 48 89 c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24 RSP: 0018:ffffc90001817be0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99 RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228 RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200 R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58 FS: 00007fe27119e740(0000) GS:ffff888148600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace:  <TASK>  ? __die_body.cold+0x19/0x27  ? die+0x2e/0x50  ? do_trap+0x159/0x1b0  ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]  ? do_error_trap+0x90/0x130  ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]  ? exc_divide_error+0x39/0x50  ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]  ? asm_exc_divide_error+0x1a/0x20  ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs]  ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]  ? seq_read_iter+0x42e/0x790  seq_read_iter+0x19a/0x790  proc_reg_read_iter+0xbe/0x110  ? __pfx_proc_reg_read_iter+0x10/0x10  vfs_read+0x469/0x570  ? do_user_addr_fault+0x398/0x760  ? __pfx_vfs_read+0x10/0x10  ? find_held_lock+0x8a/0xa0  ? __pfx_lock_release+0x10/0x10  ksys_read+0xd3/0x170  ? __pfx_ksys_read+0x10/0x10  ? __rcu_read_unlock+0x50/0x270  ? mark_held_locks+0x1a/0x90  do_syscall_64+0xbb/0x1d0  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe271288911 Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911 RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003 RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000  </TASK>  Fix this by setting cifs_server_iface::speed to a sane value (1Gbps) by default when link speed is unset.
CVE-2024-58005: In the Linux kernel, the following vulnerability has been resolved:  tpm: Change to kvalloc() in eventlog/acpi.c  The following failure was reported on HPE ProLiant D320:  [   10.693310][    T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [   10.848132][    T1] ------------[ cut here ]------------ [   10.853559][    T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [   10.862827][    T1] Modules linked in: [   10.866671][    T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [   10.882741][    T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [   10.892170][    T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [   10.898103][    T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [   10.917750][    T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [   10.923777][    T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [   10.931727][    T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0  The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().
CVE-2024-58016: In the Linux kernel, the following vulnerability has been resolved:  safesetid: check size of policy writes  syzbot attempts to write a buffer with a large size to a sysfs entry with writes handled by handle_policy_update(), triggering a warning in kmalloc.  Check the size specified for write buffers before allocating.  [PM: subject tweak]
CVE-2025-21738: In the Linux kernel, the following vulnerability has been resolved:  ata: libata-sff: Ensure that we cannot write outside the allocated buffer  reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to write outside the allocated buffer, overwriting random memory.  While a ATA device is supposed to abort a ATA_NOP command, there does seem to be a bug either in libata-sff or QEMU, where either this status is not set, or the status is cleared before read by ata_sff_hsm_move(). Anyway, that is most likely a separate bug.  Looking at __atapi_pio_bytes(), it already has a safety check to ensure that __atapi_pio_bytes() cannot write outside the allocated buffer.  Add a similar check to ata_pio_sector(), such that also ata_pio_sector() cannot write outside the allocated buffer.
CVE-2025-21745: In the Linux kernel, the following vulnerability has been resolved:  blk-cgroup: Fix class @block_class's subsystem refcount leakage  blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage.  Fix by ending the iterating with class_dev_iter_exit().
CVE-2025-21792: In the Linux kernel, the following vulnerability has been resolved:  ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockopt  If an AX25 device is bound to a socket by setting the SO_BINDTODEVICE socket option, a refcount leak will occur in ax25_release().  Commit 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()") added decrement of device refcounts in ax25_release(). In order for that to work correctly the refcounts must already be incremented when the device is bound to the socket. An AX25 device can be bound to a socket by either calling ax25_bind() or setting SO_BINDTODEVICE socket option. In both cases the refcounts should be incremented, but in fact it is done only in ax25_bind().  This bug leads to the following issue reported by Syzkaller:  ================================================================ refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31 Modules linked in: CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31 Call Trace:  <TASK>  __refcount_dec include/linux/refcount.h:336 [inline]  refcount_dec include/linux/refcount.h:351 [inline]  ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236  netdev_tracker_free include/linux/netdevice.h:4156 [inline]  netdev_put include/linux/netdevice.h:4173 [inline]  netdev_put include/linux/netdevice.h:4169 [inline]  ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069  __sock_release+0xb0/0x270 net/socket.c:640  sock_close+0x1c/0x30 net/socket.c:1408  ...  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  ...  </TASK> ================================================================  Fix the implementation of ax25_setsockopt() by adding increment of refcounts for the new device bound, and decrement of refcounts for the old unbound device.