Bug#1029602: Bug report: kernel oops in vmw_fb_dirty_flush()

[Keyu Tao]

Hi Rusin,

Thank you for your timely response. I tested that this bug is not 
reproducible in v6.2-rc5 yesterday.


On 1/31/23 03:54, Zack Rusin wrote:

On Tue, 2023-01-31 at 00:36 +0800, Keyu Tao wrote:

!! External Email

Hi vmwgfx maintainers,

An out-of-bound access in vmwgfx specific framebuffer implementation can
be easily triggered by fbterm (a framebuffer terminal emulator) when it
is going to scroll screen.

With some debugging, it seems that vmw_fb_dirty_flush() cannot handle
the vinfo.yoffset correctly after calling `ioctl(fbdev_fd,
FBIOPAN_DISPLAY, );`, and then subsequent access to the mapped
memory area causes the oops.

As current mainline vmwgfx implementation (in Linux 6.2-rc) has removed
this framebuffer implementation, this bug can be triggered only in Linux
stable. I have tested it with vanilla 6.1.8 and 5.10.165 and they all oops.

This bug is reported in
<
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2
Fcgi-
bin%2Fbugreport.cgi%3Fbug%3D1029602=05%7C01%7Czackr%40vmware.com%7C63862e731c
3b4a97796808db02e03145%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C63810693415592
2769%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
CJXVCI6Mn0%3D%7C2000%7C%7C%7C=uVOtDBAyn%2BDx5w8r1twuKO4Xd0Lma6zCr2ie3lQ%2BRR
E%3D=0> first, and
the maintainer there suggests me to report this issue to upstream :)

Relevant information (for self-compiled Linux 6.1.8):

- /proc/version: Linux version 6.1.8 (tao@mira) (gcc (Debian 10.2.1-6)
10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #7 SMP
PREEMPT_DYNAMIC Mon Jan 30 21:09:02 CST 2023

- Linux distribution: Debian GNU/Linux 11 (bullseye)

- Architecture (uname -mi): x86_64 unknown

- Virtualization software: VMware Fusion 13 Player

- How to reproduce:
    1. Install (or compile) fbterm
    2. Run fbterm under a tty (by a user with read & write permission to
/dev/fb0, usually users in video group), and try to make it scroll (for
example by pressing Enter for a few seconds)
    3. The graphics hang and it oops.



Thanks a lot for the detailed report. Is there any chance that you could try 
any of
the 6.2 rc releases to see if you can reproduce? We removed all of the hand 
rolled
fb code and ported it to drm helpers in change:
df42523c12f8 ("drm/vmwgfx: Port the framebuffer code to drm fb helpers")
which for the first time got into the official kernel in v6.2-rc1 . So any 
kernel
after that shouldn't crash with fbterm, if anyone could verify that'd be much
appreciated.

z

Bug#1029602: Bug report: kernel oops in vmw_fb_dirty_flush()

[Keyu Tao]

Hi vmwgfx maintainers,

An out-of-bound access in vmwgfx specific framebuffer implementation can 
be easily triggered by fbterm (a framebuffer terminal emulator) when it 
is going to scroll screen.


With some debugging, it seems that vmw_fb_dirty_flush() cannot handle 
the vinfo.yoffset correctly after calling `ioctl(fbdev_fd, 
FBIOPAN_DISPLAY, );`, and then subsequent access to the mapped 
memory area causes the oops.


As current mainline vmwgfx implementation (in Linux 6.2-rc) has removed 
this framebuffer implementation, this bug can be triggered only in Linux 
stable. I have tested it with vanilla 6.1.8 and 5.10.165 and they all oops.


This bug is reported in 
 first, and 
the maintainer there suggests me to report this issue to upstream :)


Relevant information (for self-compiled Linux 6.1.8):

- /proc/version: Linux version 6.1.8 (tao@mira) (gcc (Debian 10.2.1-6) 
10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #7 SMP 
PREEMPT_DYNAMIC Mon Jan 30 21:09:02 CST 2023


- Linux distribution: Debian GNU/Linux 11 (bullseye)

- Architecture (uname -mi): x86_64 unknown

- Virtualization software: VMware Fusion 13 Player

- How to reproduce:
  1. Install (or compile) fbterm
  2. Run fbterm under a tty (by a user with read & write permission to 
/dev/fb0, usually users in video group), and try to make it scroll (for 
example by pressing Enter for a few seconds)

  3. The graphics hang and it oops.

- decoded oops message:

[   31.519514] BUG: unable to handle page fault for address: 
a7c5019d6000

[   31.519843] #PF: supervisor write access in kernel mode
[   31.520149] #PF: error_code(0x0002) - not-present page
[   31.520453] PGD 167 P4D 167 PUD 11bc067 PMD 31f0d067 PTE 0
[   31.520784] Oops: 0002 [#1] PREEMPT SMP PTI
[   31.521022] CPU: 0 PID: 7 Comm: kworker/0:0 Kdump: loaded Not tainted 
6.1.8 #7
[   31.521266] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 11/12/2020

[   31.521796] Workqueue: events vmw_fb_dirty_flush [vmwgfx]
[   31.522080] RIP: 0010:memcpy_orig 
(/home/tao/Downloads/linux-6.1.8/arch/x86/lib/memcpy_64.S:85)
[ 31.522396] Code: 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe 7c 35 48 83 ea 
20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 8b 5e 18 48 8d 76 20 
<4c> 89 07 4c 89 4f 08 4c 89 57 10 4c 89 5f 18 48 8d 7f 20 73 d4 83

All code

   0:   00 48 89add%cl,-0x77(%rax)
   3:   f8  clc
   4:   48 83 fa 20 cmp$0x20,%rdx
   8:   72 7e   jb 0x88
   a:   40 38 fecmp%dil,%sil
   d:   7c 35   jl 0x44
   f:   48 83 ea 20 sub$0x20,%rdx
  13:   48 83 ea 20 sub$0x20,%rdx
  17:   4c 8b 06mov(%rsi),%r8
  1a:   4c 8b 4e 08 mov0x8(%rsi),%r9
  1e:   4c 8b 56 10 mov0x10(%rsi),%r10
  22:   4c 8b 5e 18 mov0x18(%rsi),%r11
  26:   48 8d 76 20 lea0x20(%rsi),%rsi
  2a:*  4c 89 07mov%r8,(%rdi)   <-- trapping 
instruction
  2d:   4c 89 4f 08 mov%r9,0x8(%rdi)
  31:   4c 89 57 10 mov%r10,0x10(%rdi)
  35:   4c 89 5f 18 mov%r11,0x18(%rdi)
  39:   48 8d 7f 20 lea0x20(%rdi),%rdi
  3d:   73 d4   jae0x13
  3f:   83  .byte 0x83

Code starting with the faulting instruction
===
   0:   4c 89 07mov%r8,(%rdi)
   3:   4c 89 4f 08 mov%r9,0x8(%rdi)
   7:   4c 89 57 10 mov%r10,0x10(%rdi)
   b:   4c 89 5f 18 mov%r11,0x18(%rdi)
   f:   48 8d 7f 20 lea0x20(%rdi),%rdi
  13:   73 d4   jae0xffe9
  15:   83  .byte 0x83
[   31.523208] RSP: 0018:a7c50005be10 EFLAGS: 00010202
[   31.523555] RAX: a7c5019d5c00 RBX: 0c80 RCX: 
0c80
[   31.523841] RDX: 0840 RSI: a7c500e73a20 RDI: 
a7c5019d6000
[   31.524071] RBP:  R08:  R09: 

[   31.524299] R10:  R11:  R12: 
a7c500e73600
[   31.524525] R13: 97ba70af4cd8 R14: 97ba70b4 R15: 
97ba70af4800
[   31.524753] FS:  () GS:97ba9180() 
knlGS:

[   31.524981] CS:  0010 DS:  ES:  CR0: 80050033
[   31.525209] CR2: a7c5019d6000 CR3: 37a10002 CR4: 
003706f0

[   31.525440] Call Trace:
[   31.525670]  
[   31.525900] vmw_fb_dirty_flush 
(/home/tao/Downloads/linux-6.1.8/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c:244) 
vmwgfx
[   31.526162] process_one_work 
(/home/tao/Downloads/linux-6.1.8/kernel/workqueue.c:2289)
[   31.526399] worker_thread 
(/home/tao/Downloads/linux-6.1.8/./include/linux/list.h:292 

Bug#1029602: vmwgfx: kernel oops when using fbterm in vmware

[Keyu Tao]

Continued testing and found that this bug:

- Not reproducible in current Linux 6.2-rcX mainline
- Reproducible in Linux 6.1.7-1 (bookworm kernel package)

The git history of drivers/gpu/drm/vmwgfx shows that the offending 
function `vmw_fb_dirty_flush()` in file vmwgfx_fb.c has been removed by 
commit df42523c12f8d58a41f547f471b46deffd18c203. It seems that vmwgfx 
will use "drm fb helpers" instead of its own fb implementation in Linux 
6.2.x so this bug is gone in mainline.


I'm going to send bug report to upstream after a working 6.1.x vanilla 
kernel compiled and tested, as it seems certain that this issue exists 
in all stable & LTS kernels before current mainline 6.2-rcX.


On 1/29/23 20:56, Salvatore Bonaccorso wrote:

Hi,

On Sun, Jan 29, 2023 at 04:46:38PM +0800, taoky wrote:

Hi Bonaccorso,

I have tested the vanilla 5.10.165 and the 6.0.12-1 in bullseye-backports,
and they both have this bug.

I'm going to compile a mainline kernel and then report this bug. BTW, I'm
not sure... does it mean to Cc 1029...@bugs.debian.org when reporting to
upstream to "keep in the loop"?


Yes, Cc the Debian downstream bug as well so we keep informed. It's
not a must but helps noticing if there is upstream change/fix for the
issue. Alternatively let us know when the report has happened upstream
and set the bug forwarded to the upstream report.

Regards,
Salvatore

Bug#1029602: vmwgfx: kernel oops when using fbterm in vmware

[Keyu Tao]

Did some simple debugging on fbterm just now, and I found out that 
kernel oops when fbterm running `Screen::move()` 
(<https://github.com/sfzhi/fbterm/blob/master/src/screen.cpp#L146>)


The most suspicious function inside is setupOffset(), which calls an 
ioctl(), setting yoffset:


```
void FbDev::setupOffset()
{
vinfo.yoffset = mOffsetCur;
ioctl(fbdev_fd, FBIOPAN_DISPLAY, );
}
```

And the "yoffset" may be used in `src_ptr` as `par->fb_y` in 
vmw_fb_dirty_flush():


```
if (w && h) {
dst_ptr = (u8 *)virtual  +
(dst_y1 * par->set_fb->pitches[0] + dst_x1 * cpp);
src_ptr = (u8 *)par->vmalloc +
((dst_y1 + par->fb_y) * info->fix.line_length +
(dst_x1 + par->fb_x) * cpp);

while (h-- > 0) {
memcpy(dst_ptr, src_ptr, w*cpp);
dst_ptr += par->set_fb->pitches[0];
src_ptr += info->fix.line_length;
}

// ...
```

(so it is a out-of-bound read for real?)

On 1/25/23 18:18, Keyu Tao wrote:

Source: linux
Severity: normal
X-Debbugs-Cc: taok...@outlook.com

Dear Maintainer,

It seems that fbterm triggers an out-of-bound memory write (memcpy) when vmwgfx 
loads.

Dmesg oops message:

[  214.780971] BUG: unable to handle page fault for address: ae3dc1171000
[  214.781348] #PF: supervisor write access in kernel mode
[  214.781691] #PF: error_code(0x0002) - not-present page
[  214.782130] PGD 167 P4D 167 PUD 11b3067 PMD 2427067 PTE 0
[  214.782610] Oops: 0002 [#1] SMP PTI
[  214.783069] CPU: 0 PID: 372 Comm: kworker/0:4 Kdump: loaded Not tainted 
5.10.0-21-amd64 #1 Debian 5.10.162-1
[  214.783902] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 07/22/2020
[  214.784694] Workqueue: events vmw_fb_dirty_flush [vmwgfx]
[  214.785153] RIP: 0010:memcpy_orig+0x29/0x123
[  214.785765] Code: 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe 7c 35 48 83 ea 20 48 83 
ea 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 8b 5e 18 48 8d 76 20 <4c> 89 07 4c 89 
4f 08 4c 89 57 10 4c 89 5f 18 48 8d 7f 20 73 d4 83
[  214.787323] RSP: 0018:ae3dc0807e00 EFLAGS: 00010202
[  214.787721] RAX: ae3dc1170c00 RBX: 9f70f41c9000 RCX: 0c80
[  214.788147] RDX: 0840 RSI: ae3dc0e93a20 RDI: ae3dc1171000
[  214.788553] RBP:  R08:  R09: 
[  214.788983] R10:  R11:  R12: ae3dc0e93600
[  214.789386] R13: 9f70f41c94e8 R14: 9f70e2c56400 R15: 0c80
[  214.790137] FS:  () GS:9f711180() 
knlGS:
[  214.790680] CS:  0010 DS:  ES:  CR0: 80050033
[  214.791290] CR2: ae3dc1171000 CR3: 2360a003 CR4: 003706f0
[  214.791729] Call Trace:
[  214.792302]  vmw_fb_dirty_flush+0x247/0x350 [vmwgfx]
[  214.792777]  process_one_work+0x1b3/0x350
[  214.793187]  worker_thread+0x53/0x3e0
[  214.793626]  ? process_one_work+0x350/0x350
[  214.794045]  kthread+0x118/0x140
[  214.794448]  ? __kthread_bind_mask+0x60/0x60
[  214.794871]  ret_from_fork+0x1f/0x30
[  214.795260] Modules linked in: xt_conntrack xt_MASQUERADE 
nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter 
iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter 
bridge stp llc intel_rapl_msr intel_rapl_common intel_pmc_core kvm_intel kvm 
irqbypass rapl overlay vmw_balloon btusb btrtl btbcm joydev btintel pcspkr 
serio_raw bluetooth snd_ens1371 snd_ac97_codec ac97_bus gameport snd_rawmidi 
snd_seq_device jitterentropy_rng snd_pcm snd_timer drbg ansi_cprng snd 
ecdh_generic rfkill soundcore ecc sg vsock_loopback 
vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci ac 
evdev binfmt_misc parport_pc ppdev nfsd configfs fuse lp parport auth_rpcgss 
nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath 
linear md_mod dm_mirror dm_region_hash dm_log dm_mod
[  214.795316]  hid_generic usbhid hid sd_mod t10_pi crc_t10dif 
crct10dif_generic crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel 
sr_mod cdrom ghash_clmulni_intel ata_generic vmwgfx aesni_intel xhci_pci libaes 
crypto_simd ttm cryptd ata_piix glue_helper drm_kms_helper cec xhci_hcd 
ehci_pci drm uhci_hcd mptspi mptscsih ehci_hcd mptbase libata psmouse 
scsi_transport_spi usbcore e1000 usb_common scsi_mod i2c_piix4 button
[  214.803260] CR2: ae3dc1171000
[  214.803722] ---[ end trace d0b2266ea0877554 ]---
[  214.804283] RIP: 0010:memcpy_orig+0x29/0x123
[  214.804727] Code: 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe 7c 35 48 83 ea 20 48 83 
ea 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 8b 5e 18 48 8d 76 20 <4c> 89 07 4c 89 
4f 08 

Bug#1029602: vmwgfx: kernel oops when using fbterm in vmware

[Keyu Tao]

Source: linux
Severity: normal
X-Debbugs-Cc: taok...@outlook.com

Dear Maintainer,

It seems that fbterm triggers an out-of-bound memory write (memcpy) when vmwgfx 
loads.

Dmesg oops message:

[  214.780971] BUG: unable to handle page fault for address: ae3dc1171000
[  214.781348] #PF: supervisor write access in kernel mode
[  214.781691] #PF: error_code(0x0002) - not-present page
[  214.782130] PGD 167 P4D 167 PUD 11b3067 PMD 2427067 PTE 0
[  214.782610] Oops: 0002 [#1] SMP PTI
[  214.783069] CPU: 0 PID: 372 Comm: kworker/0:4 Kdump: loaded Not tainted 
5.10.0-21-amd64 #1 Debian 5.10.162-1
[  214.783902] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 07/22/2020
[  214.784694] Workqueue: events vmw_fb_dirty_flush [vmwgfx]
[  214.785153] RIP: 0010:memcpy_orig+0x29/0x123
[  214.785765] Code: 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe 7c 35 48 83 ea 20 
48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 8b 5e 18 48 8d 76 20 <4c> 89 07 
4c 89 4f 08 4c 89 57 10 4c 89 5f 18 48 8d 7f 20 73 d4 83
[  214.787323] RSP: 0018:ae3dc0807e00 EFLAGS: 00010202
[  214.787721] RAX: ae3dc1170c00 RBX: 9f70f41c9000 RCX: 0c80
[  214.788147] RDX: 0840 RSI: ae3dc0e93a20 RDI: ae3dc1171000
[  214.788553] RBP:  R08:  R09: 
[  214.788983] R10:  R11:  R12: ae3dc0e93600
[  214.789386] R13: 9f70f41c94e8 R14: 9f70e2c56400 R15: 0c80
[  214.790137] FS:  () GS:9f711180() 
knlGS:
[  214.790680] CS:  0010 DS:  ES:  CR0: 80050033
[  214.791290] CR2: ae3dc1171000 CR3: 2360a003 CR4: 003706f0
[  214.791729] Call Trace:
[  214.792302]  vmw_fb_dirty_flush+0x247/0x350 [vmwgfx]
[  214.792777]  process_one_work+0x1b3/0x350
[  214.793187]  worker_thread+0x53/0x3e0
[  214.793626]  ? process_one_work+0x350/0x350
[  214.794045]  kthread+0x118/0x140
[  214.794448]  ? __kthread_bind_mask+0x60/0x60
[  214.794871]  ret_from_fork+0x1f/0x30
[  214.795260] Modules linked in: xt_conntrack xt_MASQUERADE 
nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter 
iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter 
bridge stp llc intel_rapl_msr intel_rapl_common intel_pmc_core kvm_intel kvm 
irqbypass rapl overlay vmw_balloon btusb btrtl btbcm joydev btintel pcspkr 
serio_raw bluetooth snd_ens1371 snd_ac97_codec ac97_bus gameport snd_rawmidi 
snd_seq_device jitterentropy_rng snd_pcm snd_timer drbg ansi_cprng snd 
ecdh_generic rfkill soundcore ecc sg vsock_loopback 
vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci ac 
evdev binfmt_misc parport_pc ppdev nfsd configfs fuse lp parport auth_rpcgss 
nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath 
linear md_mod dm_mirror dm_region_hash dm_log dm_mod
[  214.795316]  hid_generic usbhid hid sd_mod t10_pi crc_t10dif 
crct10dif_generic crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel 
sr_mod cdrom ghash_clmulni_intel ata_generic vmwgfx aesni_intel xhci_pci libaes 
crypto_simd ttm cryptd ata_piix glue_helper drm_kms_helper cec xhci_hcd 
ehci_pci drm uhci_hcd mptspi mptscsih ehci_hcd mptbase libata psmouse 
scsi_transport_spi usbcore e1000 usb_common scsi_mod i2c_piix4 button
[  214.803260] CR2: ae3dc1171000
[  214.803722] ---[ end trace d0b2266ea0877554 ]---
[  214.804283] RIP: 0010:memcpy_orig+0x29/0x123
[  214.804727] Code: 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe 7c 35 48 83 ea 20 
48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 8b 5e 18 48 8d 76 20 <4c> 89 07 
4c 89 4f 08 4c 89 57 10 4c 89 5f 18 48 8d 7f 20 73 d4 83
[  214.806126] RSP: 0018:ae3dc0807e00 EFLAGS: 00010202
[  214.806585] RAX: ae3dc1170c00 RBX: 9f70f41c9000 RCX: 0c80
[  214.807069] RDX: 0840 RSI: ae3dc0e93a20 RDI: ae3dc1171000
[  214.807549] RBP:  R08:  R09: 
[  214.808025] R10:  R11:  R12: ae3dc0e93600
[  214.808658] R13: 9f70f41c94e8 R14: 9f70e2c56400 R15: 0c80
[  214.809137] FS:  () GS:9f711180() 
knlGS:
[  214.809596] CS:  0010 DS:  ES:  CR0: 80050033
[  214.810078] CR2: ae3dc1171000 CR3: 2360a003 CR4: 003706f0

How to reproduce:

1. sudo apt install fbterm
2. Switch to TTY (such as tty1), and run fbterm by users with read and write 
permission to /dev/fb0
3. Run fbterm, and hold Enter for a few seconds (to make it scroll)
4. Oops!


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')

Bug#1029294: dnf-plugins-core reposync plugin requires a higher version of dnf package

[Keyu Tao]

Package: dnf-plugins-core
Version: 4.3.1-2~bpo11+1
Severity: important
X-Debbugs-Cc: taok...@outlook.com

Dear Maintainer,

dnf-plugins-core provides a reposync implementation as the alternative of the 
nonexist package yum-utils.
In /usr/lib/python3/dist-packages/dnf-plugins/reposync.py, it calls:

```
base._download_remote_payloads(payloads, drpm, progress, None, False)
```

However, in dnf 4.5.2, the current version in bullseye and bookworm, this 
function only takes 4 positional arguments:

(/usr/lib/python3/dist-packages/dnf/base.py)

```
def _download_remote_payloads(self, payloads, drpm, progress, callback_total):
```

In dnf 4.14.0, the current version in sid, it takes 5 positional arguments:

```
def _download_remote_payloads(self, payloads, drpm, progress, callback_total, 
fail_fast=True):
```

Thus the reposync plugin may not be usable in bookworm (and 
bullseye-backports): You may meet following backtrace:

```
Traceback (most recent call last):
  File "/usr/bin/dnf", line 58, in 
main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3/dist-packages/dnf/cli/main.py", line 201, in user_main
errcode = main(args)
  File "/usr/lib/python3/dist-packages/dnf/cli/main.py", line 67, in main
return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3/dist-packages/dnf/cli/main.py", line 106, in _main
return cli_run(cli, base)
  File "/usr/lib/python3/dist-packages/dnf/cli/main.py", line 122, in cli_run
cli.run()
  File "/usr/lib/python3/dist-packages/dnf/cli/cli.py", line 1167, in run
return self.command.run()
  File "/usr/lib/python3/dist-packages/dnf-plugins/reposync.py", line 157, in 
run
self.download_packages(pkglist)
  File "/usr/lib/python3/dist-packages/dnf-plugins/reposync.py", line 306, in 
download_packages
base._download_remote_payloads(payloads, drpm, progress, None, False)
TypeError: _download_remote_payloads() takes 5 positional arguments but 6 were 
given
```

For reproducing this bug, I created a config file (k8s.conf):

```
[main]
keepcache=0
cachedir=/tmp/

[kubernetes-el7-x86_64]
name=kubernetes-el7-x86_64
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
repo_gpgcheck=0
gpgcheck=0
enabled=1
```

And then:

```
dnf reposync -a x86_64 -c k8s.conf --delete -p /path/to/packages
```

Although I'm using the backported version of dnf-plugins-core, it's certain 
that this bug should also affects bookworm (testing).

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnf-plugins-core depends on:
ii  dnf   4.5.2-6
ii  python3   3.9.2-3
ii  python3-dbus  1.2.16-5
ii  python3-dnf   4.5.2-6

dnf-plugins-core recommends no packages.

dnf-plugins-core suggests no packages.

-- Configuration Files:
/etc/dnf/plugins/local.conf changed [not included]

-- no debconf information

Bug#1029290: dnf-plugins-core: Changelog plugin needs python3-dateutil as its dependency

[Keyu Tao]

Package: dnf-plugins-core
Version: 4.3.1-2~bpo11+1
Severity: normal
X-Debbugs-Cc: taok...@outlook.com

Dear Maintainer,

`dnf-plugins-core` does not include python3-dateutil as its dependency. 
When running commands like `dnf reposync`, it will display a "plugin load 
failure" warning like this:

```
Failed loading plugin "changelog": No module named 'dateutil'
```

It seems that it does not affect other plugins running, but it looks a little 
bit anonying.
Installing python3-dateutil silences this warning. Thus it may be necessary to 
make python3-dateutil
as dep or rec of dnf-plugins-core.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnf-plugins-core depends on:
ii  dnf   4.5.2-6
ii  python3   3.9.2-3
ii  python3-dbus  1.2.16-5
ii  python3-dnf   4.5.2-6

dnf-plugins-core recommends no packages.

dnf-plugins-core suggests no packages.

-- no debconf information